On Tue, 24 Mar 2009, Theodore Tso wrote:It is always interesting to try to explain to users that just because fsck ran cleanly does not mean anything that they care about is actually safely on disk. The speed that fsck can run at is important when you are trying to recover data from a really hosed file system, but that is thankfully relatively rare for most people.
With ext2 after a system crash you need to run fsck. With ext4, fsck
isn't an issue,
Bah. A corrupt filesystem is a corrupt filesystem. Whether you have to fsck it or not should be a secondary concern.
I personally find silent corruption to be _worse_ than the non-silent one. At least if there's some program that says "oops, your inode so-and-so seems to be scrogged" that's better than just silently having bad data in it.
Of course, never having bad data _nor_ needing fsck is clearly optimal. data=ordered gets pretty close (and data=journal is unacceptable for performance reasons).
But I really don't understand filesystem people who think that "fsck" is the important part, regardless of whether the data is valid or not. That's just stupid and _obviously_ bogus.
Linus