Messages in this thread | | | Subject | Re: scary ext2 filesystem question | From | Zlatko Calusic <> | Date | 02 Jan 1999 06:11:23 +0100 |
| |
"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/
| |