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