Re: fsck.xfs proposed improvements

[Mike Ashton <mike@fysh.org>]

On Thu, Apr 23, 2009 at 07:45:25AM -0500, Eric Sandeen wrote:

> It certainly does sound like an interesting idea, but others' concerns
> are relevant too.  The issues around how the root filesystem gets
> mounted would need to be pretty clearly addressed.  Maybe you can spell
> out your original proposal again, with updates to handle that issue?
>
> (as an aside, there have been arguments in the past that readonly mounts
> should not do recovery at all - i.e. "mount -o ro" doesn't just mean
> that you can only read the filesystem, but that the mount will only ever
> read the block device...)

I propose firstly that that behaviour should be configurable by per
filesystem tuning, making it possible to set a root filesystem to
default to norecovery on a read-only mount.  Then non-initrd mounting
of / should always succeed, getting us access to fsck.xfs.

I secondly, and I'm going to broke here, propose that
xfs_check/xfs_repair (as invocations, not the code!) should be
deprecated and both programs should be called fsck.xfs. When called
with that name, they would have the following (familiar) semantics:

fsck.xfs: verify journal integrity.  
	If it's good, return "filesystem is clean" and exit.
        If it's bad, invoke xfs_clean behaviour

fsck.xfs -f:   invoke xfs_clean behaviour even with a good journal

fsck.xfs -a: verify journal integrity
	If it's good, return "filesystem is clean" and exit.
        If it's bad, invoke xfs_repair -L behaviour

(and so on)

This makes fsck.xfs behave analogously to fsck.ext2 and friends, with
it's clean and dirty flag.  The improvement xfs offers over ext2 in
this area is that a filesystem is not only clean if shut down cleanly,
but is also clean if shutdown unclearly but with a usable journal, but
without behaving worse than ext2 by fsck.xfs thinking (incorrectly)
that a filesystem repair will never be needed and giving a filesystem
that won't mount a clean bill of health.

With both these proposals implemented, both initrd and non-initrd boot
processes would correctly handle xfs filesystem checking, using the
xfs journal to give the current excellent general case performance but
provide a safe approach to corrupted journals, without the need for
specific xfs-related care from distribution maintainers.

Thanks,
Mike.

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