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>]

It's now gone back to a pattern from a full week ago:

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


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?


Regards,
Martin




On 19/11/13 06:34, Martin wrote:
> Continuing:
> 
> gdb bt now gives:
> 
> #0  0x000000000042075a in btrfs_search_slot ()
> #1  0x0000000000427bb4 in btrfs_read_block_groups ()
> #2  0x0000000000423e40 in btrfs_setup_all_roots ()
> #3  0x000000000042406d in __open_ctree_fd ()
> #4  0x0000000000424126 in open_ctree_fs_info ()
> #5  0x000000000041812e in cmd_check ()
> #6  0x0000000000404904 in main ()
> 
> #0  0x00000000004208bc in btrfs_search_slot ()
> #1  0x0000000000427bb4 in btrfs_read_block_groups ()
> #2  0x0000000000423e40 in btrfs_setup_all_roots ()
> #3  0x000000000042406d in __open_ctree_fd ()
> #4  0x0000000000424126 in open_ctree_fs_info ()
> #5  0x000000000041812e in cmd_check ()
> #6  0x0000000000404904 in main ()
> 
> #0  0x00000000004208d0 in btrfs_search_slot ()
> #1  0x0000000000427bb4 in btrfs_read_block_groups ()
> #2  0x0000000000423e40 in btrfs_setup_all_roots ()
> #3  0x000000000042406d in __open_ctree_fd ()
> #4  0x0000000000424126 in open_ctree_fs_info ()
> #5  0x000000000041812e in cmd_check ()
> #6  0x0000000000404904 in main ()
> 
> 
> Still no further output. btrfsck running at 100% on a single core and
> with no apparent disk activity. All for a 2TB hdd.
> 
> 
> Should it take this long?...
> 
> Regards,
> Martin
> 
> 
> 
> 
> On 15/11/13 17:18, Martin wrote:
>> Another two days and a backtrace shows the hope of progress:
>>
>> #0  0x000000000041de2f in btrfs_node_key ()
>> #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 ()
>>
>> No other output, 100% CPU, using only a single core, and no apparent
>> disk activity.
>>
>> There looks to be a repeating pattern of calls. Is this working though
>> the same test repeated per btrfs block? Are there any variables that can
>> be checked with gdb to see how far it has gone so as to guess how long
>> it might need to run?
>>
>>
>> Phew?
>>
>> Hope of interest,
>>
>> Regards,
>> Martin
>>
>>
>>
>>
>> On 13/11/13 12:08, Martin wrote:
>>> 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".
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>