From: Chris Mason <chris.mason@oracle.com>
To: Jim Schutt <jaschut@sandia.gov>
Cc: Josef Bacik <josef@redhat.com>, linux-btrfs@vger.kernel.org
Subject: Re: kernel BUG at fs/btrfs/extent_io.c:3982!
Date: Wed, 11 Apr 2012 20:29:46 -0400 [thread overview]
Message-ID: <20120412002946.GF29506@shiny> (raw)
In-Reply-To: <4F85F9FB.5020007@sandia.gov>
On Wed, Apr 11, 2012 at 03:39:07PM -0600, Jim Schutt wrote:
> On 04/11/2012 02:28 PM, Josef Bacik wrote:
> >On Wed, Apr 11, 2012 at 02:24:30PM -0600, Jim Schutt wrote:
> >>On 04/11/2012 01:09 PM, Josef Bacik wrote:
> >>>On Tue, Apr 10, 2012 at 01:39:14PM -0600, Jim Schutt wrote:
> >>>>Hi,
> >>>>
> >>>>I hit this BUG today.
> >>>>
> >>>>I'm running 3.3.1 merged with the ceph and btrfs bits for 3.4,
> >>>>i.e. 3.3.1 +
> >>>> commit bc3f116fec194 "Btrfs: update the checks for mixed block groups with big metadata blocks"
> >>>> commit c666601a935b9 "rbd: move snap_rwsem to the device, rename to header_rwsem"
> >>>>
> >>>>The btrfs filesystem in question is backing a Ceph OSD under
> >>>>a heavy write load.
> >>>>
> >>>>Here's the bug:
> >>>>
> >>>
> >>>Can you give this a whirl and let me know how it goes? If I'm right you should
> >>>see a warning pop up in your messages. Thanks,
> >>
> >>OK, I've got my test running with your patch applied
> >>to my previous kernel.
> >>
> >>Do you expect your warning to only fire when my
> >>previous kernel would have BUGged? I ask because I've
> >>only seen the BUG once, so it may be a low-probability
> >>occurrence.
> >>
> >>It seems like I should keep testing until I see either
> >>your new warning or the BUG, right?
> >>
> >
> >So hopefully you will see my WARN with no BUG, but yes keep running until you
> >see one or the other please ;). Thanks,
>
> Hmmm, the BUG won:
>
> [ 6202.249041] ------------[ cut here ]------------
> [ 6202.253654] kernel BUG at fs/btrfs/extent_io.c:3989!
Since this is exactly the same call trace, we can assume ref count on
the buffer is correct. I think it means we're racing on removing the
buffer from the radix tree. I'm adding some diagnostics here to try and
grow the window a bit.
-chris
next prev parent reply other threads:[~2012-04-12 0:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-10 19:39 kernel BUG at fs/btrfs/extent_io.c:3982! Jim Schutt
2012-04-10 20:24 ` Chris Mason
2012-04-10 20:32 ` Jim Schutt
2012-04-11 19:09 ` Josef Bacik
2012-04-11 20:24 ` Jim Schutt
2012-04-11 20:28 ` Josef Bacik
2012-04-11 21:39 ` Jim Schutt
2012-04-12 0:29 ` Chris Mason [this message]
2012-05-01 16:00 ` Josef Bacik
2012-05-01 16:41 ` Jim Schutt
2012-05-03 14:43 ` Jim Schutt
2012-05-03 14:53 ` Josef Bacik
2012-05-03 15:46 ` [EXTERNAL] " Jim Schutt
2012-05-03 15:53 ` Josef Bacik
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=20120412002946.GF29506@shiny \
--to=chris.mason@oracle.com \
--cc=jaschut@sandia.gov \
--cc=josef@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.