The test is really pretty simple. It is hooked to a machine that cycles the power. It runs for 5 minutes and then the power is turned off for 1 minute (to simulate the plug being pulled). For this last set of tests it has 3 hard drives connected, one Parallel IDE and two Serial ATA. The system boots a minimal install of Fedora Core 2 from the IDE drive. No tests are running on the IDE drive. In the rc.local file it starts the fsstress test http://ltp.sf.net/nfs/fsstress.tgz(...) and the three scripts below (to simulate writing into a log file) on each of the SATA drives.
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.[1]
None of the other journaling file systems have come anywhere near this performance. After 3 or 4 power cycles, ReiserFS became corrupted to the point that the system would not boot up (the fsck failed and the bootup stopped there). XFS never got corrupted to the point it wouldn't boot, but with approximately 100 power cycles on each drive, one drive had 73 corrupted lines and the other had 82. With JFS after 15 power cycles one of the drives was corrupted and the system would no longer boot up (fsck failed again).
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.
Should I report these problems to the upstream projects (Reiser, XFS, JFS)?
[1] Ce problème des 2 lignes perdus est "normal". Il est expliqué par Alan Cox plus loin.
[^] # Re: Incroyable...
Posté par fabb . En réponse à la dépêche KDE 3.4 officiellement sorti. Évalué à 1.
Si ext3 c'est de la merde, il ne serait pas utilisé si massivement.
Un test ext3/reiserfs/xfs/jfs :
https://www.redhat.com/archives/fedora-list/2004-July/msg00418.html(...)
[1] Ce problème des 2 lignes perdus est "normal". Il est expliqué par Alan Cox plus loin.