[PATCH] btrfs_read_block_groups: Use enums to index btrfs_space_info->block_groups.

>From 33e376755b8a928610032a1cef024dcdd980aee3 Mon Sep 17 00:00:00 2001 From: chandan Date: Tue, 16 Jul 2013 12:28:56 +0530 Subject: [PATCH] btrfs_read_block_groups: Use enums to index btrfs_space_info->block_groups. The current code uses integer literals to index btrfs_space_info->block_groups[

Errors found in extent allocation tree (was: btrfsck: cmds-check.c:2063: check_owner_ref: Assertion `!(rec->is_root)' failed.)

Josef, Thanks for your help so far. I am continuing on your recommendations: 08:55 knoppix: ok i pushed to for-knoppix 08:55 pull and build 08:55 and then run ./btrfsck --init-csum-tree /dev/whatever 08:55 it will clear your csum tree and re-populate it 08:55 once thats done re-run ./btrfs

[PATCH] Btrfs/tracepoint: update delayed ref tracepoints

This shows exactly how btrfs processes the delayed refs onto disks, which is very helpful on understanding delayed ref mechanism and debugging related bugs. Signed-off-by: Liu Bo --- fs/btrfs/delayed-ref.c |6 ++-- fs/btrfs/extent-tree.c |6 include/trace/events/btrfs.h

Re: filebench varmail + scrubber = btrfs_update_root bug

On Mon, Jul 15, 2013 at 12:56:29AM -0400, George Amvrosiadis wrote: > I'm trying to run the varmail personality in filebench, on a 50GB btrfs > filesystem. I am also starting the scrubber at the same time. I have > applied the latest patches for 3.8.13 (hoping to fix log tree issues). There's a bu

Bug in btrfs check

Hi, I have found (probably) a bug in btrfs check. I have a file system with errors (potentially a broken disk, although smartctl and badblocks didn't reveal any errors I keep getting file system corruptions). When I try to repair it using "btrfs check /dev/sdb1", the tool aborts after a while: [r

Re: filebench varmail + scrubber = btrfs_update_root bug

On Tue, 16 Jul 2013 13:37:45 +0200, David Sterba wrote: > On Mon, Jul 15, 2013 at 12:56:29AM -0400, George Amvrosiadis wrote: >> I'm trying to run the varmail personality in filebench, on a 50GB btrfs >> filesystem. I am also starting the scrubber at the same time. I have >> applied the latest patc

[PATCH] Btrfs: Print key type in decimal everywhere

This is confusing, sometimes the key type is printed in hex (without a leading "0x" which makes things even more complicated), sometimes in decimal... Change it to be in decimal everywhere. Signed-off-by: Stefan Behrens --- fs/btrfs/print-tree.c | 4 ++-- 1 file changed, 2 insertions(+), 2 delet

Re: [PATCH] Btrfs: fix lock leak when resuming snapshot deletion

On Mon, Jul 15, 2013 at 7:43 PM, Josef Bacik wrote: > We aren't setting path->locks[level] when we resume a snapshot deletion which > means we won't unlock the buffer when we free the path. This causes deadlocks > if we happen to re-allocate the block before we've evicted the extent buffer > from

Re: filebench varmail + scrubber = btrfs_update_root bug

FYI, updating to 3.10 seems to have solved the problem (after some rigorous testing, I haven't been able to trigger the BUG again). > > item 0 key (18446744073709551606 80 6597246976) > Is (objectid = -10 = BTRFS_EXTENT_CSUM_OBJECTID, type = 0x80 = > BTRFS_EXTENT_CSUM_KEY) > > > > unable to update

Re: [PATCH] Btrfs: Print key type in decimal everywhere

On Tue, Jul 16, 2013 at 03:38:33PM +0200, Stefan Behrens wrote: > This is confusing, sometimes the key type is printed in hex (without > a leading "0x" which makes things even more complicated), sometimes > in decimal... > Change it to be in decimal everywhere. This seems particularly reasonable t

btrfsck disk explenation

This is a nice overview https://btrfs.wiki.kernel.org/index.php/Data_Structures but does not show how things work. Would be helpful if there was a presentation that shows what happens when for example you copy a file to understand the use of each tree better? I don't understand what went wrong in

Re: Need help mounting broken btrfs Fedora 19

Any other suggestions? On Mon, Jul 15, 2013 at 6:56 AM, Dave Barnum wrote: > Thanks Wang, > > This was the result: > root@ubuntu:/downloads/btrfs-progs# ./btrfs chunk-recover /dev/sdc2 > no recoverable chunk > Recover the chunk tree successfully. > > Still unable to mount. > > On Sun, Jul 14, 201

Re: [PATCH 4/4] btrfs: offline dedupe

On Mon, 15 Jul 2013 13:55:51 -0700, Zach Brown wrote: > I'd get rid of all this code by only copying each input argument on to > the stack as it's needed and by getting rid of the writable output > struct fields. (more on this later) > As I said, I'd get rid of the output fields. Like the other

Re: [PATCH] btrfs-progs: Add chunk corrupt funtion to btrfs-corrupt-block

Since the new chunk recovery patches are merged, what about merging this patch to add chunk corruption function? :) Qu 于 2013年06月07日 10:25, Qu Wenruo 写道: > Add chunk corrupt function to btrfs-corrupt-block. > This funtion can be used to delete or corrupt a given chunk or the whole > chunk tree. >

Re: [PATCH 1/2] btrfs-progs: fix the long lines

Strings being grep-able is important. Thanks Stefan and Eric for the comments. Hopefully we shall have some better ways to handle long strings. OR shorter error message and still communicate the intended message is another choice but challenging. :-) I have dropped this patch for now.