Re: fsck.xfs proposed improvements

[Mike Ashton <mike@fysh.org>]

On Thu, Apr 23, 2009 at 11:19:45AM -0500, Russell Cattelan wrote:

> Traditional thinking with a journaled filesystem has been that if
> there is a dirty log then you do not want to risk mounting the
> filesystem in an inconsistent state an thereby risking a system
> crash or file system shutdown due to that inconsistent state.

Although I don't think you're doing anything more dangerous than
mounting a non-fsck'd non-journaling filesystem read-only, which is
the traditional unix boot method when you're not using initrd, I do
accept that I've introduced a non-zero chance of a system crash in
situations where everything is fine.  I think I've thought of a
compromise.

I propose the addition of a new mount semantic, let's call it
"tryrecovery" for now, which will replay a log if possible or mount
the filesystem in an inconsistent state otherwise.  So you would mark
a filesystem as being a root fs, enabling this behaviour, and the
kernel's attempt to mount its root filesystem would invoke this
behaviour without the explicit knowledge of lilo, grub, kernel
parameters, etc.

I believe this would address both our concerns.  In the general case,
the behaviour will be as it is now; the journal is played, the root
filesystem will be mounted into known a good states and there's no
chance of a crash, but if everything's gone to hell, we allow
fingers-crossed access to the filesystem to be able to get access to
the xfs_repair tool.

> Also in the case of a mount -norecover with any subsequent repair
> being done, it is probably
> best to reboot at that point to ensure there is no bad FS data that
> may be in cache.

A remount to read/write ought to invalidate any cache/buffers for
exactly that reason.

Cheers,
Mike.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs