[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <499D30B1.30802@aei.mpg.de>
Date: Thu, 19 Feb 2009 11:13:05 +0100
From: Carsten Aulbert <carsten.aulbert@....mpg.de>
To: "xfs@....sgi.com" <xfs@....sgi.com>, linux-kernel@...r.kernel.org,
npiggin@...e.de
Subject: Re: xfs problems (possibly after upgrading from linux kernel 2.6.27.10
to .14)
Hi again,
Dave Chinner schrieb:
>> 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?
>
> If you unmount the filesystem, mount it again and then touch a new
> file and it reports the error again, then yes, a metadump woul dbe
> great.
>
> If the error doesn't show up after a unmount/mount, then I
> can't use a metadump image to reproduce the problem.
>
I've done it on two nodes so far and the result is not good (metadump wise):
[1344887.778232] Filesystem "sda6": xfs_log_force: error 5 returned.
[1344887.778432] xfs_force_shutdown(sda6,0x1) called from line 420 of
file fs/xfs/xfs_rw.c. Return address = 0xffffffff8031dd7e
[1344889.579836] Filesystem "sda6": xfs_log_force: error 5 returned.
[1344889.580044] Filesystem "sda6": xfs_log_force: error 5 returned.
[1344889.580257] Filesystem "sda6": xfs_log_force: error 5 returned.
[1344889.580450] Filesystem "sda6": xfs_log_force: error 5 returned.
[1344889.624774] Filesystem "sda6": xfs_log_force: error 5 returned.
[1344915.783844] XFS mounting filesystem sda6
[1344915.872333] Starting XFS recovery on filesystem: sda6 (logdev:
internal)
[1344917.399834] Ending XFS recovery on filesystem: sda6 (logdev: internal)
After that I can touch/create all files I want on the fs again.
> I suspect so. We've already had XFS trigger one bug in the new
> lockless pagecache code, and the fix for that went in 2.6.27.11 -
> between the good version and the version that you've been seeing
> these memory corruptions on. I'm wondering if that fix exposed or
> introduced another bug that you've hit....
>
> Nick?
If it was triggered by a user job, it might have been in the kernel for
longer and the user just did not run it for a few weeks.
I'll try to gather more information.
Cheers
Carsten
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists