Re: btrfs unmountable after failed suspend

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 8, 2012 at 2:26 PM, Chris Mason <chris.mason@xxxxxxxxxx> wrote:
> 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.

I certainly hope it's not just bad ram. I just got this laptop half a year ago!
I'll try to get a fsck output when I get home..
>
> -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


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux