-------- Original Message --------
Subject: Re: btrfs check segfaults after flipping 2 Bytes
From: Duncan <1i5t5.dun...@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. =:^)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
