[Top] [All Lists]

Re: fsck.xfs proposed improvements

To: xfs@xxxxxxxxxxx
Subject: Re: fsck.xfs proposed improvements
From: Mike Ashton <mike@xxxxxxxx>
Date: Wed, 22 Apr 2009 10:45:27 +0100
In-reply-to: <49EE441E.6040606@xxxxxxxxxxx>
References: <mailman.0.1240318659.128675.xfs@xxxxxxxxxxx> <20090421142333.GA5197@xxxxxxxx> <49EE441E.6040606@xxxxxxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
On Tue, Apr 21, 2009 at 05:09:34PM -0500, Russell Cattelan wrote:

Hi Russell (and others reading), and thanks for your reply.

> Well step back a bit, fsck.xfs exists simply to satisfy the initial
> boot scripts that invokes fsck -t $fs_type.  The reason fsck.xfs
> does nothing and should continue to do nothing is that by the time
> you have access to the boot scripts and the fsck.xfs program the
> root filesystem has already been mounted. Which means the root file
> system has successfully made it through either a clean mount or a
> log replay mount, neither of which needs additional verification.

Now that's an interesting point; I hadn't seen it quite like that
before.  It's now very clear to me that there's a semantic
inconsistency between xfs and, say, ext2 in that the initial read only
mount of ext2 is more directly analogous to a read-only _norecovery_
mount of xfs.  The filesystem at that stage might be in an
inconsistent state, but there's an expectation that you'll be able to
read fsck (/xfs_repair) from it.  By handling the "fsck stage" at the
time of the initial read only mount, some fragility has been
introduced into the process.  The filesystem now only mounts if it's
in a consistent state (bad!), even though we've redefined what
"consistent" means to refer to journal integrity rather than the
underlying filesystem integrity (good).  With badly behaved hardware,
which seem prevalent, or any bugs which do get into xfs we could
actually end up with xfs being less fault tolerant and less reliable
in general use than other filesystems, which would be a bit of a

> It would not be unreasonable to do what you are suggesting in an
> initrd startup script, provided xfs_repair was included in the
> initrd (which has size and library requirements).

I think we can do it on direct mounts, but only if we can get to the
bottom of readonly/norecovery semantics.  Obviously we don't
necessarily want readonly mounts to be non recovered by default
(although there is an argument for that).  

Would it be crazy to propose a filesystem flag to control which
default recovery behaviour a filesystem has?  A root filesystem isn't
mounted read-only except a) on boot and b) when being tinkered with by
someone competent, so I think it would be useful to be able to tell
such a filesystem that it shouldn't attempt journal recovery on
readonly mount, which would enable a meaningful use of a meaningful
fsck.  What do you think about that?

> This would probably be a matter of first implementing it and then
> convincing the mkinitrd maintainers to add the support.

I'm a bit out of my depth with the politics of that.  This would be a
different person for each distribution?


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