Re: Lost file-system story

[Donald Allen <donaldcallen%gmail.com@localhost>]

On Sat, Dec 10, 2011 at 1:14 PM, Edgar Fuß <ef%math.uni-bonn.de@localhost> 
wrote:
> My impression is that you are asking for the impossible.
>
> The underlying misconception (which I know very well for suffering from it 
> myself) is that a filesystem aims at keeping the on-disc metadata consistent 
> and that tools like fsck are intended to rapair any inconsistencies happening 
> nontheless.
>
> This, I learned, is not true.
>
> The point of syncronous metadata writes, soft dependency metadata write 
> re-ordering, logging/journaling/WAPBL and whatnot is _not_ to keep the 
> on-disc metadata consistent. The sole point is to, under all adverse 
> conditions, leave that metadata in a state that can be _put back_ into a 
> consistent state (peferrably reflecting an in-memory state not too far back 
> from the time of the crash) by fsck, on-mount journal replay or whatever.
> That difference becomes perfectly clear with journalling. After an unclean 
> shutdown, the on-disc metadata need not be consistent. But the journal 
> enables putting it back into a consistent state quite easily.
> So fsck is not aimed at and does not claim to be able to recover from random 
> inconsistencies in the on-disc metadata. It is aimed at repairing those 
> inconsistencies that can occur because a crash _given the metadata was 
> written syncronously_.
> FreeBSD's background fsck, by the way, is aimed at reparing only those 
> inconsistencies that can occur given the metadata was written with softep's 
> re-ordering.
>
> Of course, keeping the on-disc metadata in a ``repairable'' state incurs a 
> performance penalty.
>
> So you seem to be asking for the File System Holy Grail: a file system that 
> is as fast as asyncronous metadata writes, yet able to survive any possible 
> kind of unclean shutdown. Such a thing, to my knowledge, doesn't exist.

I'm sorry, I don't wish to be rude, but you, too, seem not to have
read what I've written carefully. Or, perhaps the fault is mine, that
I simply haven't made myself sufficiently clear. I've talked at length
about the behavior of Linux ext2 and that it was more than acceptable,
both from a standpoint of performance and reliability. I am not
looking for something "able to survive any possible kind of unclean
shutdown". I'm looking for a reasonably low joint probability of a
crash occurring *and* losing an async-mounted filesystem as a result.
I simply want an async implementation where the benefit (performance)
is not out-weighed by the risk (lost filesystems) and I cited Linux
ext2 is an example of that. If that's not clear to you, then I'm
afraid I can't do better.