[Top] [All Lists]

Re: fsck.xfs proposed improvements

To: xfs@xxxxxxxxxxx
Subject: Re: fsck.xfs proposed improvements
From: Mike Ashton <mike@xxxxxxxx>
Date: Fri, 24 Apr 2009 10:21:29 +0100
In-reply-to: <49F09521.9000103@xxxxxxxxxxx>
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> <49F09521.9000103@xxxxxxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
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

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.


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