Slashdot Mirror
Benchmarking Linux Filesystems In New 2.6 Kernel
An anonymous reader writes "KernelTrap has an interesting article about a recent benchmark conducted to compare five journaling filesystems available with the current 2.6.0-test2 Linux development kernel. The tests were conducted with a very simple shell script, mainly timing how long it takes to copy, tar, and remove directories. Looks like reiser4 is the fastest filesystem at the expense of consuming much more CPU, with ext3 trailing a ways behind."
From the article:
"reiser4 171.28s, 30%CPU (1.0000x time; 1.0x CPU)
reiserfs 302.53s, 16%CPU (1.7663x time; 0.53x CPU)
What's interesting:
* reiser4 had highest throughput and most CPU usage"
The comparison seems incomplete to me. Reiser4 took about half the time, with twice the CPU usage. The
Total Work Done by the CPU = Percent * Time.
Reiser4 did the work in half the time, but the total work was roughly equal. Actually, ReiserFS was more efficient considering total CPU cycles.
It seems to me to me that these benchmarks would probably have been more meaningful (and useful) if they had run the same tests against 2.4.21. Anybody got any thoughts on this? I know there are low-latency features and so forth with the new kernel, but I would be curious to know if that has any real impact on disk I/O.
Stability should be at the top of the list when desigining a filesystem. If its a quetsion of stability or speed, stability should win.
I think another interesting metric to look at would be cpu time used. If one of them took 90% CPU for 10 seconds, that would be a big winner imo.
reiser4 171.28s @ 30% CPU = 51.384s CPU
reiserfs 302.53s @ 16% CPU = 48.4048s CPU
ext3 319.71s @ 11% CPU = 35.1681s CPU
xfs 429.79s @ 13% CPU = 55.8727s CPU
jfs 470.88s @ 6% CPU = 28.2528s CPU
I did a dd to dump the whole filesystem to a file in a larger filesystem for recovery purposes. The XFS tools that came with RedHat 7.1 seemed to crash so I did a small slackware install and went from there. xfs_restore and other tools sounding like xfs_sync or something found my third superblock. I used it to reconstruct the other superblocks. The root and early directories were gone, and the files I needed were in the root directory, well the xfs_restore linked them all to numbered directories and files. A few greps later I was in a directory that had those files all intact. I recovered around 80% of all the files, and 100% of the ones I was seeking. Just because I succeeded in one major recovery op from an XFS filesystem, I feel confident with it more than the ext3 or reiser guys. I havent really compared them.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
quick question, what mount options were used on each? Wouldn't e3fs appear slower than the others if it was data-journaling? (I read the article a bit fast, but I didn't see any "how we tested") Also wouldn't a good test take at least two hours on each filesystem?
I'm not convinced. ext3 under 2.4 on SMP can be cripplingly slow entirely for software reasons--lock_kernel() being the biggest culprit.
Having said that, my new big fileserver is going to be ext3 on 2.6 (eventually!); the data volumes being on a 12-way RAID-5 set and the journals on a RAID-1 pair. It seems to perform adequately with dir_index and sparse_super.
The main thing that swings it for me is the brilliant e2fsck.