lkml.org 
[lkml]   [1998]   [Dec]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: scary ext2 filesystem question
On 25 Dec 1998, Mirian Crzig Lennox 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*. I couldn't figure
> out how that could be, unless it was due to some kind of bug in the
> caching code, not a flaw in the design of the filesystem.

I wouldn't go so far as to say that Mr. Giampaolo misunderstood something,
just that it is possible to read an incorrect implication (which is hard
to judge, outside of context.) To the best of my knowledge, he is quite
correct that ext2 does not guarantee consistency of on-disk data. This is
quite beside the fact the buffer cache compensates for this. If the power
goes out (or someone mucks with the disk directly), you do very much care
whether the disk is consistent, and this is _not_ the same issue as write
caching. A file system can be designed (in cooperation with the write
cache) so that it always is in a consistent (if not necessarily ideal)
state after each physical write. ext2 forgoes some of this, in favour of
speed.

And, yes, none of this is an issue in normal use. Files on any file system
should not "self destruct" for some esoteric reason. That is a bug, not a
design choice. But I very much doubt Mr. Giampaolo was trying to say that,
and I'm willing to give him the benefit of that doubt.

> > I noted the name of the author in my ignore list ... obviuosly he did not
> > understand anything!
>
> I'm inclined to agree, especially since elsewhere he refers to ext2 as
> "the fast and unsafe grandchild" of FFS.

Again, to the best of my knowledge, this is not an inaccurate statement.
ext2 was built on some of the techniques used in FFS, among others, and is
comparitively faster, with less consistency.

All of this discussion aside, I'd like to question the idea that if an
author wishes to discuss the technical merits of ext2 or any other part of
Linux, this is a reason to _ignore_ them if they get it wrong? If you feel
someone has done a poor job, then a reasoned critique would be better for
all concerned. Ignorance (or poor editing) is usually a correctable
problem, after all.

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)



-
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/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:1.310 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site