On Sat, Dec 10, 2011 at 1:14 PM, Edgar Fuß <e...@math.uni-bonn.de> 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.
