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 quick question: Will the release of btrfsck later this month be able to fix these corruptions? > > 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. > > -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
