linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: Karl Mardoff Kittilsen <karl@kittilsen.org>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: kernel BUG at /build/buildd/linux-3.2.0/fs/btrfs/extent-tree.c:4816!
Date: Tue, 29 Nov 2011 10:49:13 -0500	[thread overview]
Message-ID: <20111129154913.GN24338@shiny> (raw)
In-Reply-To: <4ED4FA72.5050804@kittilsen.org>

On Tue, Nov 29, 2011 at 04:29:54PM +0100, Karl Mardoff Kittilsen wrote:
> Den 29. nov. 2011 16:12, skrev Chris Mason:
> >On Tue, Nov 29, 2011 at 02:39:26AM +0100, Karl Mardoff Kittilsen wrote:
> >>Hi!
> >>
> >>Sending a mail on this issue, as advised on IRC.
> >>
> >>My /home file system fails to mount and the kernel seem to freeze
> >>and I need to do the Alt+SysRq RSNEIUB routine to boot it safely.
> >>The corruption happened on a 3.2-rc<something>  kernel and Ubuntu
> >>11.10, but I am now running on Ubuntu 12.04 with the 3.2.0-2-generic
> >>kernel to see if that helped, it did not.
> >>btrfsck from the latest btrfs-tools returns:
> >>
> >>karl@karl-precise:~/git/btrfs-progs$ sudo ./btrfsck /dev/md0
> >>ref mismatch on [2176962560 8192] extent item 480, found 1
> >>Incorrect local backref count on 2176970752 root 5 owner 2101705
> >>offset 368640 found 1 wanted 3925868545
> >>backpointer mismatch on [2176970752 4096]
> >
> >So the crashes below were because we tried to free one of these extents.
> >You have two extents whose reference counts are way off.
> >
> >Unfortunately this is stored on disk, so different kernels aren't going
> >to fix it (yet).  One of the extents is in a file with inode number
> >2101705, and the other is in a btree block (2176962560).
> >
> >I'll be able to fix this soon, but we can also make a patch that changes
> >those BUG_ONs to just deal with the mismatch.  The worst case here would
> >be leaking those two extents, about 12K of data.
> >
> >-chris
> 
> Thank you for looking into it, and that does sounds really
> promising. I am available to test any patches you want tested. Is
> there anything else that I can do to help getting this issue fixed?

The good news about this one is that it is very clear cut.  The hard
part is figuring out where these bogus link counts came from.

I'd suggest that you spend some time running memtest on the machine.

-chris


  reply	other threads:[~2011-11-29 15:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-29  1:39 kernel BUG at /build/buildd/linux-3.2.0/fs/btrfs/extent-tree.c:4816! Karl Mardoff Kittilsen
2011-11-29 15:12 ` Chris Mason
2011-11-29 15:29   ` Karl Mardoff Kittilsen
2011-11-29 15:49     ` Chris Mason [this message]
2011-11-29 16:47       ` David Sterba
2011-11-29 18:12         ` Chris Mason
2011-12-15  0:01           ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111129154913.GN24338@shiny \
    --to=chris.mason@oracle.com \
    --cc=karl@kittilsen.org \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).