lkml.org 
[lkml]   [1999]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: scary ext2 filesystem question
From
Date
"Theodore Y. Ts'o" <tytso@MIT.EDU> writes:

> It's impossible to do this without doing full atomic commits, using a
> transaction based filesystem, and these often suffer from significant
> performance losses over non-atomic filesystems.
>
> What's happening here is that the data blocks didn't get synced out to
> disk, but the meta-data *did* make it out to disk. This will happen
> under both the BSD FFS and Linux ext2 implementations, since neither
> attempts to do any write ordering with respect to the data file. It's
> simply too expensive.
>

OK, I understand this.

> The difference between the BSD FFS and the Linux Ext2 implementation is
> that by default, the BSD FFS will do synchronous write ordering of the
> *metadata*, whereas Linux doesn't. In Linux, we rely on a superior fsck
> to take care of metadata inconsistencies, whereas BSD takes a
> performance hit in order to simplify fsck's job. (For example, if a
> block is claimed by multiple inodes, the BSD fsck will simply delete
> both inodes, whereas the Linux e2fsck will offer to clone the multiply
> claimed blocks; one file will still likely be corrupted, possibly just
> in one block or two --- but that's better than losing *all* of both
> files which is what the BSD fsck does.)
>

Well, the confusing part is that fsck reports some size/count changes
(I don't remember the exact error message right now), something like
inode number x, was y, should be z, corrected. Now, if I write down
that inode numbers, and find corresponding files after fsck finishes,
they are in many cases corrupted (maybe in all cases?). I was always
wondering, what would happen if fsck DID NOT repair the files. After
all, it knows that older value.

Pardon my ignorance, I didn't found time so far to investigate inner
workings of ext2/fsck (even though I wanted).

> For both operating systems, though, in case of an unclean shutdown, what
> you describe is likely going to happen. Might I suggest a UPS, or other
> ways of simply preventing the unclean shutdown in the first place?
>

I'm connected to a great, big UPS, so that in the last 2 years I
didn't have a single power failure. Nice, isn't it?

Now, what that UPS can't do is prevent me from "improving" kernel
sources and making mistakes along a way. If you by any chance get hold
of a model with such functionality, please inform me fast where should
I go and buy it. :)

Regards,
--
Zlatko

-
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:49    [W:0.090 / U:0.608 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site