On 06/25/2013 01:03 AM, Josef Bacik wrote:
On Fri, Jun 21, 2013 at 03:32:28PM +0800, Anand Jain wrote:
btrfs-progs has to read fs info from the kernel to
read the latest info instead of reading it from the disks,
which generally is a stale info after certain critical
operation.
getting used_b
Thanks for commenting Josef. I hope your head will get better:)
Actually, while re-looking at the code, I see that there are couple of
"goto cleanup;", before we ensure that all the writers have detached
from the committing transaction. So Liu's code is still needed, looks
like.
Thanks,
Alex.
On
Hi Miao,
I believe the name of this patch is misleading. The significant
contribution of this patch IMO is the btrfs_release_ref_cluster(),
which is being called when btrfs_run_delayed_refs() aborts the
transaction. Without this fix, btrfs_destroy_delayed_refs() was
crashing when it was doing:
list
> >> This would save some CPU cycles for the repeated le64_to_cpu() and for
> >> the memcpy(). The number of lines of code is equal for both ways.
> >
> > Hmm? It would be many fewer lines of code.
>
> Are you thinking of something shorter than the following?
That's better, yeah, but there's st
Andrea Gelmini posted on Mon, 24 Jun 2013 18:45:39 +0200 as excerpted:
> 2013/6/24 Josef Bacik :
>> Could you make an image of this fs for me and upload it somewhere so I
>> can pull it down and run some stuff on it? I've
>
> n.b.: I've got a lot of sensible/private data in my home, but maybe we
On Fri, Jun 21, 2013 at 03:32:28PM +0800, Anand Jain wrote:
> btrfs-progs has to read fs info from the kernel to
> read the latest info instead of reading it from the disks,
> which generally is a stale info after certain critical
> operation.
>
> getting used_bytes parameter will help to fix
>
2013/6/24 Josef Bacik :
> On Sun, Jun 23, 2013 at 05:33:59AM +0200, Andrea Gelmini wrote:
> So it looks like you just have a few transid mismatches but we manage to find
> something that works out just fine. Could you make an image of this fs for me
> and upload it somewhere so I can pull it down
On Fri, 21 Jun 2013 09:11:38 -0700, Zach Brown wrote:
+ offset = (unsigned long)ptr;
+ while (sub_item_len > 0) {
+ u64 data;
+
+ read_extent_buffer(eb, &data, offset, sizeof(data));
+ data = le64_to_cpu(data);
+ if (data == s
On Sun, Jun 23, 2013 at 05:33:59AM +0200, Andrea Gelmini wrote:
> Hi everybody,
>and thanks a lot for your work.
>
>I have this problem.
>With latest 3.9 kernel and btrfs-next I was close to full my home.
>The system went read only mode while I was copying in some files.
>
>Ev
On Sun, Jun 23, 2013 at 09:52:14PM +0300, Alex Lyakas wrote:
> Hello Josef, Liu,
> I am reviewing commits in the mainline tree:
>
> e4a2bcaca9643e7430207810653222fc5187f2be Btrfs: if we aren't
> committing just end the transaction if we error out
> (call end_transaction() instead of goto cleanup_t
On Sun, Jun 23, 2013 at 11:41:33PM +0100, Miguel Negrão wrote:
> Hi,
>
> I want to do a backup of a btrfs subvolume from one disk to another
> disk, both with btrfs filesystems, using the btrfs send receive
> functionality. I do
>
> cd /media/miguel/btrfs_backup/
> mkdir backups
> sudo btrfs se
On Mon, Jun 24, 2013 at 12:25:07PM +0200, Ondřej Kunc wrote:
> Hi developers,
>
> I have been playing with btrfs on our test server. I have streessed it
> much ... and I can say ... it's troughput and features are very nice
> and usable, but I experienced one problem during testing, btrfs
> trigge
On Mon, Jun 24, 2013 at 02:22:30PM +0200, Martin Mailand wrote:
> Hi,
>
> I tried 3.10.0-rc7 with the btrfs option skinny extents (btrfstune -x),
> I get this warning after a few seconds of ceph workload.
>
Can you file a bug at bugzilla.kernel.org and make sure the component is set to
btrfs. A
There are a few problems with btrfs/265. First we don't redirect the output of
btrfs fi ba somwhere else, so we fail this test outright. Secondly if you have
less than 4 devices in your scratch dev pool it won't work because you can't
mkfs raid10 without 4 devices. This is all impossible to figu
On Fri, Jun 21, 2013 at 04:53:54PM -0500, Eric Sandeen wrote:
> On 6/21/13 3:30 PM, Josef Bacik wrote:
> > Btrfs will default to mixed block groups for 1 gigabyte file systems and
> > smaller, which means data and metadata share the same area. This makes
> > generic/274 fail for us because we cann
Hi,
I tried 3.10.0-rc7 with the btrfs option skinny extents (btrfstune -x),
I get this warning after a few seconds of ceph workload.
-martin
[ 1153.897960] [ cut here ]
[ 1153.897977] WARNING: at fs/btrfs/backref.c:903
find_parent_nodes+0x107f/0x1090 [btrfs]()
[ 1153.897
Hi developers,
I have been playing with btrfs on our test server. I have streessed it
much ... and I can say ... it's troughput and features are very nice
and usable, but I experienced one problem during testing, btrfs
triggered lockup of 3 of 8 CPU cores of testing server.
What I was doing ?
Si
It should be 'clear', not 'set'.
Signed-off-by: Wang Sheng-Hui
---
extent_io.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/extent_io.c b/extent_io.c
index 5093aeb..8f51250 100644
--- a/extent_io.c
+++ b/extent_io.c
@@ -197,7 +197,7 @@ static int clear_state_bit(struct
18 matches
Mail list logo
