OT - Journaling File Systems?
Alan Cox
alan at redhat.com
Fri Jul 2 16:38:01 UTC 2004
On Fri, Jul 02, 2004 at 11:22:20AM -0500, Edwards, Scott (MED, Kelly IT Resouces) wrote:
> The ext3 have almost a perfect record with the write cache off: I have
> run over 300 cycles on the two drives and only had two corrupted lines
> in the output files. So out of 600 total cycles on the two drives there
> were only two lines with bad data, I think that is a pretty good record.
Unless you are doing data journalling or some kind of userspace
transactions you wouldn't expect file contents to be perfect. Data
journalling has a big performance cost.
> I just can't understand what is happening, it makes no sense to me that
> one file system would be almost perfect and three would fail so
> dramatically. I am going to re-run the tests on all 4 file systems to
> verify that it is repeatable.
Your expectations seem at odds with what journalling provides. A journalled
fs can be recovered by log replay. It doesn't guarantee that user data is
recovered precisely. It guarantees that user data is recovered to those
points where it was committed.
Thus
open file O_APPEND
write stuff
close it
repeat. doesn't guarantee "stuff" will always be committed - it just
guarantees that the fs will be structurally sound
open file O_APPEND
write stuff
fsync
close
OTOH says that after the fsync has returned you can be sure the data
just wrote before it *will* still be there.
Ext3 data journalling journals everything which is a bit slower but can
be appropriate for some applications (and actually for big NFS servers
often turns out to be faster because of the NFS commit behaviour)
More information about the fedora-test-list
mailing list