xfs
[Top] [All Lists]

Re: fsck.xfs proposed improvements

To: Mike Ashton <mike@xxxxxxxx>
Subject: Re: fsck.xfs proposed improvements
From: Russell Cattelan <cattelan@xxxxxxxxxxx>
Date: Thu, 23 Apr 2009 11:19:45 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20090423143515.GA5878@xxxxxxxx>
References: <mailman.0.1240318659.128675.xfs@xxxxxxxxxxx> <20090421142333.GA5197@xxxxxxxx> <49EE441E.6040606@xxxxxxxxxxx> <20090422094527.GA16600@xxxxxxxx> <87ws9cnz14.fsf@xxxxxxxxxxxxxxxxx> <20090423084900.GB16600@xxxxxxxx> <49F062E5.70800@xxxxxxxxxxx> <20090423141432.GC16600@xxxxxxxx> <20090423143515.GA5878@xxxxxxxx>
User-agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Ashton wrote:
> 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.
>
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.
By replaying the log
even on a read only mount the file system is brought back into a known
good state.

So there are risks of mounting without recovery but I'm leaning toward
it might be an acceptable risk in a single user state
that would allow access to the root file system.
>
> 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:
Well I wouldn't go that far xfs_check is already a wrapper around
xfs_db which is a very
different animal from xfs_repair.
>
> 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)
Well again step back, most of the time at boot the mount of root
succeeds and the log has
been replayed and the fs is consistent. I don't think changing that to
a mount -norecovery all
the time is a good idea, that is risking every mount to a potentially
inconsistent state for the
rare case that the log is corrupted.

So even if we do a norecovery and then drop the system into single
user due to a corrupted log,
the only option at that point is xfs_repair -L, which is not a
recommended thing to do unless
some manual analysis  is done  and the inevitable data loss is understood.

It would be nice to eventually have an xfs_repair that could replay
the log from userspace
but that has not been implemented yet, that would allow for a clean
repair from userspace.
But again if the log is corrupted it may not be able to handle things
any better than the
kernel log recovery.

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.
>
> 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.
Given that xfs was suppose to be a fresh way of doing file systems
over the traditional UFS based
filesystems trying to make xfs behave like ext2/ext* is not really a
step forwards.

But I think there could be some improvement made to provide a less
painful way of
recovering a root fs that has a bad log.

>
> 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@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ8JUYNRmM+OaGhBgRAtllAJ9Ha2DGfoMalyjnfEggS0YhXL24BQCfZfuc
K5SglBMCSIIfzyjUsjFgTrE=
=fDCQ
-----END PGP SIGNATURE-----

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