Re: [PATCH] Btrfs-progs: allow --init-extent-tree to work when extent tree is borked

[Martin <m_btrfs@ml1.co.uk>]

On 11/11/13 22:52, Martin wrote:
> On 07/11/13 01:25, Martin wrote:

> 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

> 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 ()


Another two days and:

(gdb) bt
#0  0x000000000042373a in read_tree_block ()
#1  0x0000000000421538 in btrfs_search_slot ()
#2  0x0000000000427bb4 in btrfs_read_block_groups ()
#3  0x0000000000423e40 in btrfs_setup_all_roots ()
#4  0x000000000042406d in __open_ctree_fd ()
#5  0x0000000000424126 in open_ctree_fs_info ()
#6  0x000000000041812e in cmd_check ()
#7  0x0000000000404904 in main ()


> So... Has it looped or is it busy? There is no activity on /dev/sdc.

Same "btrfs_read_block_groups" but different stack above that: So
perhaps something useful is being done?...

No disk activity noticed.


> 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".


OK... So I'll leave running for a little while longer before trying a mount.

Some sort of progress indicator would be rather useful... Is this going
to run for a few hours more or might this need to run for weeks to
complete? Any clues to look for?

(All on a 2TByte single disk btrfs, 4k defaults)

Hope of interest.

Regards,
Martin