Re: btrfsck --repair /dev/sdc (Was: [PATCH] Btrfs-progs: allow --init-extent-tree to work when extent tree is borked)

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

>>>> I don't know if that has gone through that pattern during the week but
>>>> at a-week-a-time, this is not going to finish in reasonable time.
>>>>
>>>> How come so very slow?
>>>>
>>>> Any hints/tips/fixes or abandon the test?
>>>
>>> You're a patient man. =:^)
>>
>> Sort of... I can leave it running in the background until I come to need
>> to do something else with that machine. So... A bit of an experiment.
> 
> 
> Until... No more... And just as the gdb bt shows something a little
> different!
> 
> (gdb) bt
> #0  0x000000000041ddc4 in btrfs_comp_keys ()
> #1  0x00000000004208e9 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 ()
> 
> 
> Nearly done or weeks yet more to run?
> 
> The poor thing gets killed in the morning for new work.

OK, so that all came to naught and it got killed for a kernel update and
new work.

"Just for a giggle," I tried mounting that disk with the 'recovery'
option and it failed with the usual complaint:

btrfs: disabling disk space caching
btrfs: enabling auto recovery
parent transid verify failed on 911904604160 wanted 17448 found 17450
parent transid verify failed on 911904604160 wanted 17448 found 17450
btrfs: open_ctree failed


Trying a wild guess of "btrfs-zero-log /dev/sdc" gives:

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 sat there at 100% CPU usage, no further output, and no
apparent disk activity... Just like btrfsck was...


So... Looks like time finally for a reformat.



Any chance of outputting some indication of progress, and for a speedup,
or options for partial recovery or?... Or for a fast 'slash-and-burn'
recovery where damaged trees get cleanly amputated rather than
too-painfully-slowly repaired?...

Just a few wild ideas ;-)


Regards,
Martin