Messages in this thread | | | Date | Thu, 31 Dec 1998 19:40:14 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: scary ext2 filesystem question |
| |
From: Zlatko Calusic <Zlatko.Calusic@CARNet.hr> Date: 31 Dec 1998 16:26:15 +0100
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/
| |