[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Lost file-system story
On Sat, Dec 10, 2011 at 1:14 PM, 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
> 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
> 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.
Main Index |
Thread Index |