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.
|