From: Carsten Aulbert <carsten.aulbert@aei.mpg.de>
To: david@fromorbit.com
Cc: "xfs@oss.sgi.com" <xfs@oss.sgi.com>, linux-kernel@vger.kernel.org
Subject: Re: xfs problems (possibly after upgrading from linux kernel 2.6.27.10 to .14)
Date: Wed, 18 Feb 2009 10:36:59 +0100 [thread overview]
Message-ID: <499BD6BB.2000406@aei.mpg.de> (raw)
In-Reply-To: <20090218091935.GD8830@disturbed>
Hi Dave,
Dave Chinner schrieb:
> On Tue, Feb 17, 2009 at 03:49:16PM +0100, Carsten Aulbert wrote:
>> Hi all,
>>
>> within the past few days we hit many XFS internal errors like these. Are these
>> errors known (and possibly already fixed)? I checked the commits till
>> 2.6.27.17 and there does not seem anything related to this.
>
> .....
>
>> Feb 16 20:34:49 n0035 kernel: [275873.335916] Filesystem "sda6": XFS internal error xfs_trans_cancel at line 1164 of file fs/xfs/xfs_
>
> A transaction shutdown on create. That implies some kind of ENOSPC
> issue.
>
>> Do you need more information or can I send these nodes into a re-install?
>
> More information. Can you get a machine into a state where you can
> trigger this condition reproducably by doing:
>
> mount filesystem
> touch /mnt/filesystem/some_new_file
>
> If you can get it to that state, and you can provide an xfs_metadump
> image of the filesystem when in that state, I can track down the
> problem and fix it.
I can try doing that on a few machines, would a metadump help on a
machine where this corruption occurred some time ago and is still in
this state?
>
>> Feb 16 22:01:28 n0260 kernel: [1129250.851451] Filesystem "sda6": xfs_iflush: Bad inode 1176564060 magic number 0x36b5, ptr 0xffff8801a7c06c00
>
> However, this implies some kind of memory corruption is occurring.
> That is reading the inode out of the buffer before flushing the
> in-memory state to disk. This implies someone has scribbled over
> page cache pages.
>
>
>> Feb 17 05:57:44 n0463 kernel: [1156816.912129] Filesystem "sda6": XFS internal error xfs_btree_check_sblock at line 307 of file fs/xfs/xfs_btree.c. Caller 0xffffffff802dd15b
>
> And that is another buffer that has been scribbled over.
> Something is corrupting the page cache, I think. Whether the
> original shutdown is caused by the some corruption, i don't
> know.
>
At least on two nodes we ran memtest86+ overnight and so far no error.
>> plus a few more nodes showing the same characteristics
>
> Hmmmm. Did this show up in 2.6.27.10? Or did it start occurring only
> after you upgraded from .10 to .14?
As far as I can see this only happened after the upgrade about 14 days
ago. What strikes me odd is that we only had this occurring massively on
Monday and Tuesday this week.
I don't know if a certain access pattern could trigger this somehow.
Cheers
Carsten
next prev parent reply other threads:[~2009-02-18 9:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-17 14:49 xfs problems (possibly after upgrading from linux kernel 2.6.27.10 to .14) Carsten Aulbert
2009-02-17 17:24 ` Eric Sandeen
2009-02-18 9:19 ` Dave Chinner
2009-02-18 9:36 ` Carsten Aulbert [this message]
2009-02-19 6:19 ` Dave Chinner
2009-02-19 10:13 ` Carsten Aulbert
2009-02-19 12:01 ` Nick Piggin
2009-02-19 13:12 ` Carsten Aulbert
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=499BD6BB.2000406@aei.mpg.de \
--to=carsten.aulbert@aei.mpg.de \
--cc=david@fromorbit.com \
--cc=linux-kernel@vger.kernel.org \
--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