Re: btrfs check segfaults after flipping 2 Bytes

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

-------- Original Message --------
Subject: Re: btrfs check segfaults after flipping 2 Bytes
From: Duncan <1i5t5.duncan@cox.net>
To: <linux-btrfs@vger.kernel.org>
Date: 2014年10月06日 12:10
> Qu Wenruo posted on Mon, 06 Oct 2014 10:29:53 +0800 as excerpted:
>
>> 2 problems here.
>>
>> [1] csum mismatch As already mentioned by Ducan and Brendan, the csum
>> does not match.
>>
>> What makes thing much worse, since small file's extent is inlined, the
>> data is stored in metadata tree blocks,
>> and the file system is almost empty so the inline extent lies in the
>> *root* leaf of fs_tree.
>> These two unfortunate facts makes the whole fs_tree corrupted(only one
>> leaf, and its cusm dismatch),
>> which cause btrfs-progs segfault.
> So I nailed it. =:^)
>
>> The good news is that, the bug in btrfs-progs is already fixed by Wang's
>> patch:
>> https://patchwork.kernel.org/patch/4254631/
>> So at least, btrfs-progs will not segfault anymore.
>>
>> [2] two occurences?
>> So you definitely changed something you should not touch... maybe
>> another tree root?
> 1) Single device btrfs, therefore...
> 2) DUP metadata by default.
Oh, I forgot this, default DUP for metadata...

Thanks
Qu.
>
> 3) Small file, therefore...
> 4) Inlined in (DUP) metadata, therefore...
>
> 5) Two occurrences, each a copy of the (metadata-inlined) file in its own
> instance of the (duped) metadata block.
>
> I nailed it again. =:^)
>
> But the connection between the mentioned tree root patch and this
> particular bug had escaped me, so that's useful new information to me
> too, resolving the problem that I spotted but had no clue whether it was
> even fixable.  Thanks.  =:^)
>