Re: scary ext2 filesystem question

david parsons (o.r.c@p.e.l.l.p.o.r.t.l.a.n.d.o.r.u.s)
25 Dec 1998 22:14:16 -0800


In article <linux.kernel.m3lnjvyd8r.fsf@trantor.cosmic.com>,
Mirian Crzig Lennox <mirian@xensei.com> wrote:
>Kurt Garloff <K.Garloff@ping.de> writes:
>> On Fri, Dec 25, 1998 at 11:42:57AM -0500, Mirian Crzig Lennox wrote:
>> > _Practical File System Design_, Dominic Giampaolo, p. 36
>>
>> Nonsense!
>> The ext2fs uses write cacheing, like any powerful filesystem does.
>> This cannot confuse any program. Any program that reads data from the disk
>> goes through the page cache, so it get's the recent data, whether it was
>> written to disk yet, or not yet. It is guaranteed to be written to disk
>> sometime, thats what bdflush/update and kswapd are for. Un unmounting the fs
>> all buffers are flushed, even if you managed to kill your bdflush before.
>
>That's exactly what I was thinking.
>
>Obviously, if [any] computer system crashes, bad things can happen.
>That was not my point of confusion; rather, I was bewildered because
>the author seemed to be implying that these kinds of problems could
>occur *even during normal filesystem operation*.

The comment about fsck failing was, at least to me, pretty clear
indication that the author was talking about what happens during
a crash.

>I'm inclined to agree, especially since elsewhere he refers to ext2 as
>"the fast and unsafe grandchild" of FFS.

I don't know if it's a grandchild of FFS, but it is a little bit
less safe theoretically (though I've managed to lose a grand total
of one file from that sort of metadata corruption in the past seven
years of running Linux-based news servers [*].)

[* Including some interesting power related crashes -- if you don't
have enough power in the box, guess when the smoke will be let
out? When all seven of your disks (and three SCSI controllers)
are cheerfully running an expire, that's when.]

____
david parsons \bi/ I suspect I've not lost any binaries, since I still
\/ have some 7-year old Linux binaries that still work,
despite traditionally living on very busy filesystems
when the system goes south for one reason or another.)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/