Re: btrfs unmountable after failed suspend

On Wed, Feb 08, 2012 at 01:22:19PM -0600, Chester wrote:

On Wed, Feb 8, 2012 at 6:55 AM, Chris Mason [off-list ref] =

wrote:

quoted

On Tue, Feb 07, 2012 at 06:10:15PM -0600, Chester wrote:

quoted

This is dmesg mounted with -o ro,recovery
[ =A0 20.957392] exe used greatest stack depth: 4920 bytes left
[ =A0145.340317] device label BtrfsLinux devid 1 transid 332442 /d=

ev/sda6

quoted

quoted

[ =A0145.341702] btrfs: enabling auto recovery
[ =A0145.341803] btrfs: disk space caching is enabled
[ =A0152.457967] btrfs: corrupt leaf, bad key order:
block=3D653297209344,root=3D1, slot=3D7
[ =A0152.487933] btrfs: corrupt leaf, bad key order:
block=3D653297209344,root=3D1, slot=3D7
[ =A0152.488326] ------------[ cut here ]------------
[ =A0152.488549] kernel BUG at fs/btrfs/extent-tree.c:5797!

Well, this isn't good. =A0If you can run btrfs-zero-log it'll get p=

ast

quoted

this part, but I'd suggest a fsck run to see if there are other
corrupted blocks.

I've already tried the -o recovery option at mount. I was told it doe=

s

the same as btrfs-zero-log (but probably less destructive). Just a

It does zero the log, but looks like it does so a little too late.  The
mount -o recovery code zeros it if we failed to read some of the tree
roots, but you're hitting the tree log before we fail.  Long story
short, you need to btrfs-zero-log ;)

quick question: Will the release of btrfsck later this month be able
to fix these corruptions?

=46ixing the key ordering is pretty easy, I can do that here.  But I'll
need to see the fsck output to say if the rest is fixed in the current
code.

quoted

Bad key ordering is usually from memory corruption, so this block
probably isn't alone.

Yeah. Could be from using zcache. I haven't had a problem with it
until I tried to suspend to RAM though.

Could be, I'd suggest running with CONFIG_DEBUG_PAGE_ALLOC.  You might
also just have bad ram.

-chris

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