tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Lost file-system story



Donald Allen <donaldcallen%gmail.com@localhost> writes:

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

I think that it should be clear that async mount excludes what you want.
Async mount basically means that you create fresh file system after boot.
In linux it may mean another thing (e.g., it may be less asynchronous),
in BSDs it means exactly that. Thus, unless you really can afford
starting file system from scratch, don't mount it async.


-- 
HE CE3OH...



Home | Main Index | Thread Index | Old Index