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

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

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