From: Eric Sandeen <sandeen@sandeen.net>
To: Mark Rechler <mrechler@brightcove.com>
Cc: xfs@oss.sgi.com
Subject: Re: XFS Kernel Panics in CentOS
Date: Mon, 02 Apr 2012 11:03:31 -0700 [thread overview]
Message-ID: <4F79E9F3.6010305@sandeen.net> (raw)
In-Reply-To: <CANoMt5O5T+FTrmL-2c5tsT=wm434iVNeFarPdybcs1q_oPtW=g@mail.gmail.com>
On 4/2/12 8:09 AM, Mark Rechler wrote:
> Hi Eric,
>
> Thank you for the reply. We are running CentOS 5.8, with the
> 2.6.18-164.10.1.el5.centos.plus kernel as it was mentioned in a bug
> report that has similar behavior, but ultimately a different kernel
> panic (http://bugs.centos.org/view.php?id=4089). We have tried
> running xfs_repair in the past and it has not proved useful. The odd
> part is that these are fresh systems (just installed). If it helps,
> we are also running glusterfs on these boxes though load does not
> always correlate to a kernel panic.
I can't say for sure what's in that respun "extra" centos kernel,
but I can say this: the error you hit indicates that xfs read a
buffer, and wound up with a metadata buffer which had unrecognized
magic - i.e. it did not look like metadata as expected. Seeing what
looks like corruption, it shut down.
This reminds me a little of
https://bugzilla.redhat.com/show_bug.cgi?id=512552
which I fixed for RHEL customers a while back, where cancelled
readahead in MD was resulting in xfs thinking a buffer was
uptodate, but in fact it was uninitialized, hence it found
garbage and shut down in this way.
Something similar seems to be happening in your case, if xfs_repair
comes up clean; somehow xfs is getting hold of a buffer which
apparently doesn't match what xfs_repair found to be a consistent
filesystem.
So I might suspect something in the storage stack?
Also please be sure you don't have kmod-xfs or xfs-kmod installed
on your centos box, which is a truly ancient and completely unsupported
backport of xfs from long, long ago.
-Eric
> Thanks,
> Mark
>
> On Fri, Mar 30, 2012 at 6:44 PM, Eric Sandeen <sandeen@sandeen.net <mailto:sandeen@sandeen.net>> wrote:
>
> On 3/30/12 5:02 PM, Mark Rechler wrote:
> > Hi Everyone,
> >
> > We've been getting a lot of errors (across several kernels) and eventually a kernel panic. Any insight into these errors would be much appreciated.
> >
> > Errors:
> > Filesystem "dm-3": XFS internal error xfs_da_do_buf(2) at line 2112 of file fs/xfs/xfs_da_btree.c. Caller 0xffffffff883c1826
>
> Saying which CentOS it is would help ;) And, standard disclaimers about how CentOS doesn't come with upstream _or_ distro support, etc etc...
>
> But xfs_da_do_buf(2) indicates on-disk corruption, having encountered a bad magic number when reading from the disk. Have you tried xfs_repair?
>
> -Eric
>
> > Call Trace:
> > [<ffffffff883c1725>] :xfs:xfs_da_do_buf+0x503/0x5b1
> > [<ffffffff883c1826>] :xfs:xfs_da_read_buf+0x16/0x1b
> > [<ffffffff883c1826>] :xfs:xfs_da_read_buf+0x16/0x1b
> > [<ffffffff883aeb71>] :xfs:xfs_attr_leaf_get+0x2e/0x99
> > [<ffffffff883aeb71>] :xfs:xfs_attr_leaf_get+0x2e/0x99
> > [<ffffffff883aec7f>] :xfs:xfs_attr_fetch+0xa3/0xd5
> > [<ffffffff883a7aa8>] :xfs:xfs_acl_iaccess+0x64/0xd4
> > [<ffffffff883f264a>] :xfs:xfs_check_acl+0x1b/0x2b
> > [<ffffffff8000f550>] generic_permission+0x40/0xca
> > [<ffffffff8000d902>] permission+0x81/0xc8
> > [<ffffffff8000999d>] __link_path_walk+0x173/0xf42
> > [<ffffffff8000e9cc>] link_path_walk+0x42/0xb2
> > [<ffffffff8000cc9c>] do_path_lookup+0x275/0x2f1
> > [<ffffffff8001278e>] getname+0x15b/0x1c2
> > [<ffffffff800236f6>] __user_walk_fd+0x37/0x4c
> > [<ffffffff8003f1f6>] vfs_lstat_fd+0x18/0x47
> > [<ffffffff8008c46e>] default_wake_function+0x0/0xe
> > [<ffffffff800efddf>] sys_lgetxattr+0x4e/0x5f
> > [<ffffffff8002a996>] sys_newlstat+0x19/0x31
> > [<ffffffff8005d229>] tracesys+0x71/0xe0
> > [<ffffffff8005d28d>] tracesys+0xd5/0xe0
> >
> > Code: 0f b6 40 02 89 44 24 04 e9 95 00 00 00 44 0f b6 Z3 44 3b 65
> > RIP [<ffffffffff8841bfaf>] :xfs:xfs_attr_shortform_getvalue+0x24/0xe2
> > RSP <ffff81020752dbc8>
> > CR2: 00000000000002
> > <0>Kernel panic - not syncing: Fatal exception
> >
> > Thanks,
> > Mark
> >
> >
> > _______________________________________________
> > xfs mailing list
> > xfs@oss.sgi.com <mailto:xfs@oss.sgi.com>
> > http://oss.sgi.com/mailman/listinfo/xfs
>
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-04-02 18:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-30 22:02 XFS Kernel Panics in CentOS Mark Rechler
2012-03-30 22:44 ` Eric Sandeen
2012-04-02 15:09 ` Mark Rechler
2012-04-02 18:03 ` Eric Sandeen [this message]
2012-06-29 4:46 ` Changliang Chen
2012-06-29 4:52 ` Eric Sandeen
2012-06-29 4:58 ` Changliang Chen
2012-06-29 15:04 ` Mark Rechler
2012-06-29 21:38 ` Stefan Ring
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=4F79E9F3.6010305@sandeen.net \
--to=sandeen@sandeen.net \
--cc=mrechler@brightcove.com \
--cc=xfs@oss.sgi.com \
/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