On 07/11/13 01:25, Martin wrote: > On 28/10/13 15:11, Josef Bacik wrote:
>> Ok I've sent >> >> [PATCH] Btrfs-progs: rework open_ctree to take flags, add a new one >> >> which should address your situation. Thanks, > > > Josef, > > Tried your patch: > > #### > Signed-off-by: Josef Bacik <jba...@fusionio.com> > > 13 files changed, 75 insertions(+), 113 deletions(-) > > diff --git a/btrfs-convert.c b/btrfs-convert.c > index 26c7b5f..ae10eed 100644 > #### > > And the patching fails due to mismatching code... > > I have the Gentoo source for: > > Btrfs v0.20-rc1-358-g194aa4a > > (On Gentoo 3.11.5, will be on 3.11.6 later today.) > > > What are the magic incantations to download your version of source code > to try please? (Patched or unpatched?) OK so Chris Mason and the Gentoo sys-fs/btrfs-progs-9999 came to the rescue to give: # btrfs version Btrfs v0.20-rc1-591-gc652e4e This time: # btrfsck --repair --init-extent-tree /dev/sdc quickly gave: parent transid verify failed on 911904604160 wanted 17448 found 17449 parent transid verify failed on 911904604160 wanted 17448 found 17449 parent transid verify failed on 911904604160 wanted 17448 found 17449 parent transid verify failed on 911904604160 wanted 17448 found 17449 Ignoring transid failure btrfs unable to find ref byte nr 910293991424 parent 0 root 1 owner 2 offset 0 btrfs unable to find ref byte nr 910293995520 parent 0 root 1 owner 1 offset 1 btrfs unable to find ref byte nr 910293999616 parent 0 root 1 owner 0 offset 1 leaf free space ret -297791851, leaf data size 3995, used 297795846 nritems 2 checking extents btrfsck: extent_io.c:609: free_extent_buffer: Assertion `!(eb->refs < 0)' failed. enabling repair mode Checking filesystem on /dev/sdc UUID: 38a60270-f9c6-4ed4-8421-4bf1253ae0b3 Creating a new extent tree Failed to find [910293991424, 168, 4096] Failed to find [910293995520, 168, 4096] Failed to find [910293999616, 168, 4096] >From that, I've tried running again: # btrfsck --repair /dev/sdc giving thus far: parent transid verify failed on 911904604160 wanted 17448 found 17450 parent transid verify failed on 911904604160 wanted 17448 found 17450 parent transid verify failed on 911904604160 wanted 17448 found 17450 parent transid verify failed on 911904604160 wanted 17448 found 17450 Ignoring transid failure ... And it is still running a couple of days later. GDB shows: (gdb) bt #0 0x000000000042d576 in read_extent_buffer () #1 0x000000000041ee79 in btrfs_check_node () #2 0x0000000000420211 in check_block () #3 0x0000000000420813 in btrfs_search_slot () #4 0x0000000000427bb4 in btrfs_read_block_groups () #5 0x0000000000423e40 in btrfs_setup_all_roots () #6 0x000000000042406d in __open_ctree_fd () #7 0x0000000000424126 in open_ctree_fs_info () #8 0x000000000041812e in cmd_check () #9 0x0000000000404904 in main () So... Has it looped or is it busy? There is no activity on /dev/sdc. Which comes to a request: Can the options "-v" (for verbose) and "-s" (to continuously show status) be added to btrfsck to give some indication of progress and what is happening? The "-s" should report progress by whatever appropriate real-time counts as done by such as "badblocks -s". I'll leave running for a little while longer before trying a mount. Hope of interest. Thanks, Martin -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
