In my experience, lots of times I get corrupted files after unclean
shutdown, that is, lots of my log files finish with zeros on their end
(probably after fsck pass which kinda fixes things in those files).
It's tedious job after that, to go and delete those unwanted zeroes
from the files, and I would be much happier if FS would indeed behave
like you're saying (lose here and there, but do NOT corrupt data).
Maybe it's the fsck program bug, after all? :)
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.
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.)
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?
- Ted
-
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/