Re: kernel BUG at fs/btrfs/extent-tree.c:8113! (4.1.3 kernel)

From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: Marc MERLIN <marc@merlins.org>
Cc: Josef Bacik <jbacik@fb.com>, <dsterba@suse.com>, <clm@fb.com>,
	<linux-btrfs@vger.kernel.org>
Subject: Re: kernel BUG at fs/btrfs/extent-tree.c:8113! (4.1.3 kernel)
Date: Mon, 24 Aug 2015 13:11:26 +0800	[thread overview]
Message-ID: <55DAA77E.10105@cn.fujitsu.com> (raw)
In-Reply-To: <20150824042800.GJ5602@merlins.org>

Marc MERLIN wrote on 2015/08/23 21:28 -0700:
> On Mon, Aug 24, 2015 at 09:10:30AM +0800, Qu Wenruo wrote:
>> Would you please take the following output?
>>
>> 1) btrfs check output
>> With error message if it happens.
>
> myth:~# btrfs check /dev/mapper/crypt_sdd1
> Checking filesystem on /dev/mapper/crypt_sdd1
> UUID: 024ba4d0-dacb-438d-9f1b-eeb34083fe49
> checking extents
> cmds-check.c:4486: add_data_backref: Assertion `back->bytes != max_size` failed.
> btrfs[0x8066a73]
> btrfs[0x8066aa4]
> btrfs[0x8067991]
> btrfs[0x806b4ab]
> btrfs[0x806b9a3]
> btrfs[0x806c5b2]
> btrfs(cmd_check+0x1088)[0x806eddf]
> btrfs(main+0x153)[0x80557c6]
> /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb753a4d3]
> btrfs[0x80557ec]
>
>> 2) btrfs check --repair output
>> Full output until segfault.
>
> myth:~# btrfs check --repair /dev/mapper/crypt_sdd1
> enabling repair mode
> Checking filesystem on /dev/mapper/crypt_sdd1
> UUID: 024ba4d0-dacb-438d-9f1b-eeb34083fe49
> checking extents
> cmds-check.c:4486: add_data_backref: Assertion `back->bytes != max_size` failed.
> btrfs[0x8066a73]
> btrfs[0x8066aa4]
> btrfs[0x8067991]
> btrfs[0x806b4ab]
> btrfs[0x806b9a3]
> btrfs[0x806c5b2]
> btrfs(cmd_check+0x1088)[0x806eddf]
> btrfs(main+0x153)[0x80557c6]
> /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb75114d3]
> btrfs[0x80557ec]
>
> Strangely I'm not getting a segfault anymore.

It seems that the tree block's backref has something wrong.

>
>> 3) btrfs-debug-tree output
>> With assert output.
>
> The full output is multi gigabyte. Do you need this and if so, do I need to
> upload it somewhere and will you download the multi gigabyte file?
>
> The errors and assert, I already posted here:
>
>>>> Sure thing:
>>>> btrfs-debug-tree /dev/mapper/crypt_sdd1 > /tmp/tree.out
>>>> parent transid verify failed on 2968115101696 wanted 34855 found 39533
>>>> parent transid verify failed on 2968115101696 wanted 34855 found 39533
>>>> parent transid verify failed on 2968115101696 wanted 34855 found 39533
>>>> parent transid verify failed on 2968115101696 wanted 34855 found 39533
>>>> Ignoring transid failure
>>>> parent transid verify failed on 2968115134464 wanted 34855 found 39533
>>>> parent transid verify failed on 2968115134464 wanted 34855 found 39533
>>>> parent transid verify failed on 2968115134464 wanted 34855 found 39533
>>>> parent transid verify failed on 2968115134464 wanted 34855 found 39533
>>>> Ignoring transid failure
>>>> parent transid verify failed on 2968115150848 wanted 34855 found 39533
>>>> parent transid verify failed on 2968115150848 wanted 34855 found 39533
>>>> parent transid verify failed on 2968115150848 wanted 34855 found 39533
>>>> parent transid verify failed on 2968115150848 wanted 34855 found 39533
>>>> Ignoring transid failure
>>>> parent transid verify failed on 2968115691520 wanted 34855 found 39533
>>>> parent transid verify failed on 2968115691520 wanted 34855 found 39533
>>>> parent transid verify failed on 2968115691520 wanted 34855 found 39533
>>>> parent transid verify failed on 2968115691520 wanted 34855 found 39533
>>>> Ignoring transid failure
>>>> parent transid verify failed on 1291597152256 wanted 35830 found 39530
>>>> parent transid verify failed on 1291597152256 wanted 35830 found 39530
>>>> parent transid verify failed on 1291597152256 wanted 35830 found 39530
>>>> parent transid verify failed on 1291597152256 wanted 35830 found 39530
>>>> Ignoring transid failure
>>>> parent transid verify failed on 2968116592640 wanted 34855 found 39533
>>>> parent transid verify failed on 2968116592640 wanted 34855 found 39533
>>>> parent transid verify failed on 2968116592640 wanted 34855 found 39533
>>>> parent transid verify failed on 2968116592640 wanted 34855 found 39533
>>>> Ignoring transid failure
>>>> parent transid verify failed on 2968116609024 wanted 34855 found 39533
>>>> parent transid verify failed on 2968116609024 wanted 34855 found 39533
>>>> parent transid verify failed on 2968116609024 wanted 34855 found 39533
>>>> parent transid verify failed on 2968116609024 wanted 34855 found 39533
>>>> Ignoring transid failure
>>>> print-tree.c:1094: btrfs_print_tree: Assertion failed.
>>>> btrfs-debug-tree[0x805ce93]
>>>> btrfs-debug-tree(btrfs_print_tree+0x26d)[0x805eb51]
>>>> btrfs-debug-tree(btrfs_print_tree+0x279)[0x805eb5d]
>>>> btrfs-debug-tree(main+0x8b5)[0x804dfb7]
>>>> /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb757c4d3]
>>>> btrfs-debug-tree[0x804e221]
Oh, sorry for ignoring the existing output.

And the last assert info should be enough. No need to upload it.

The b-tree seems to be hugely damaged, or at least one leaf tree block 
is referred by higher level node.
It maybe something wrong happened when level of a btree is reduced.

Normally, I have no idea on how to fix such huge problem in btrfsck.
But there is still some clue.

In your debug-tree output, the transid difference between wanted and 
found is quite huge. I suppose there would be a much much newer root 
tree, but not recorded in superblock.

So, my last bet will be, using "btrfs-find-root -a" to find the root 
with highest generation, and use the new root to exec "btrfsck -b 
<bytenr of highest gen root>".

The latest btrfs-find-root would output possible tree root by descending 
order of its generation. You'll find proper bytenr quite easy.
But be prepared as "btrfs-find-root -a" will iterate all metadata space, 
so it will takes a long long time to finish.
And until it scanned all the space, it won't output anything.

Thanks,
Qu
>
> Thanks,
> Marc
>