[Top] [All Lists]

[Bug 411] Reproducible memory corruption, oops, panic with xfs on sata r

To: xfs-masters@xxxxxxxxxxx
Subject: [Bug 411] Reproducible memory corruption, oops, panic with xfs on sata raid5 in 2.6
From: bugzilla-daemon@xxxxxxxxxxx
Date: Sun, 15 Feb 2009 14:41:21 -0600
Auto-submitted: auto-generated
In-reply-to: <bug-411-113@xxxxxxxxxxxxxxxx/bugzilla/>
References: <bug-411-113@xxxxxxxxxxxxxxxx/bugzilla/>

--- Comment #18 from Andras Korn <korn-sgi.com@xxxxxxxxxxxxxxxxxxxxxx>  
2009-02-15 14:41:19 CST ---
No, what I meant was it would be ideal not to have to run xfs_repair at all.

The problem is that if this filesystem were being mounted at boot, from fstab,
and the mount failed, the boot process would basically stop, possibly leaving
the box inaccessible (e.g. if this was the rootfs). Sure, there are ways around
that, but they're expensive and/or painful.

This is handled for other filesystems by running fsck on them before mounting
(if they're dirty), but afaict fsck.xfs is a no-op: it's either mount, or
xfs_repair and lose journal data.

If I understand what you said about the patch correctly, mounting would be
impossible (so that if this were the rootfs, we'd be in trouble already);
initscripts would have to be smartened to first attempt mounting xfs, then, if
that failed, run xfs_repair on it and attempt mounting again afterwards.
Running xfs_repair is a bad idea because it can't replay the log.

So, long story short: ideally either the kernel should handle recovery of even
such pathologically broken filesystems, or xfs_repair should be able to replay
the log (making it safe to run on a dirty fs before mounting).

Configure bugmail: http://oss.sgi.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

<Prev in Thread] Current Thread [Next in Thread>