Re: Lost file-system story

[Edgar Fuß <ef%math.uni-bonn.de@localhost>]

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.