On Wed, Feb 08, 2012 at 01:22:19PM -0600, Chester wrote: > On Wed, Feb 8, 2012 at 6:55 AM, Chris Mason <chris.mason@xxxxxxxxxx> wrote: > > On Tue, Feb 07, 2012 at 06:10:15PM -0600, Chester wrote: > >> This is dmesg mounted with -o ro,recovery > >> [ 20.957392] exe used greatest stack depth: 4920 bytes left > >> [ 145.340317] device label BtrfsLinux devid 1 transid 332442 /dev/sda6 > >> [ 145.341702] btrfs: enabling auto recovery > >> [ 145.341803] btrfs: disk space caching is enabled > >> [ 152.457967] btrfs: corrupt leaf, bad key order: > >> block=653297209344,root=1, slot=7 > >> [ 152.487933] btrfs: corrupt leaf, bad key order: > >> block=653297209344,root=1, slot=7 > >> [ 152.488326] ------------[ cut here ]------------ > >> [ 152.488549] kernel BUG at fs/btrfs/extent-tree.c:5797! > > > > Well, this isn't good. If you can run btrfs-zero-log it'll get past > > 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 does > 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? Fixing 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. > > > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
