Mike Benoit recently posted a link to results from his new and improved file system shootout, using better hardware and running more tests. Using two benchmarks that are designed to measure hard drive and file system performance, Bonnie++ and IOZone, he's compared a number journaling filesystems found in the 2.6 kernel [forum]. Included in the lineup are EXT2 (not journaling, but an effective baseline [story]), JFS, XFS, ReiserFS, Reiser4, and EXT3 each compared head to head on both SCSI and IDE drives.
In Mike's summary he labels JFS and XFS as 'best bang for your buck' explaining, "While not the fastest file systems, both of them consistently perform close to EXT2, while using minimal CPU. XFS seems to be faster over a wider range of benchmarks, however it does use slightly more CPU than JFS. While JFS really starts to slow down with lots of files." As for pure speed, Mike points to Reiser4 which really shined in the Bonnie++ benchmarks, though not quite so much in the IOZone benchmarks. He suggests, "ReiserFS v4 will [definitely] be worth while keeping an eye on, especially considering some of the exciting new features it offers."
From: Mike Benoit [email blocked] To: linux-kernel, [email blocked] Subject: File System shootout v2.1 using an AMD Opteron 240... Date: Fri, 24 Oct 2003 13:54:59 -0700 Since the last shootout was so popular, I was able to get my hands on some better hardware to run even more tests. As well the generated results format was improved slightly. Bonnie++ and IOZone results on an AMD Opteron 240 system, comparing 2.6.0test5,test7,test8 as well as SCSI vs. IDE are now posted for your viewing pleasure at: http://fsbench.netnation.com/ -- Best Regards, Mike Benoit
Graphs
Too much reading. May I suggest future benchmarks have pretty graphs? :-)
Bonnie Suite
I have a project in Sourceforge named "Bonnie Suite" that does the same and some more tests than Bonnie ++, and, amoung others things, displays graphs.
You can take an example of the benchmark suite output here.
This benchmark thing is extremely complicated.
Mike's work is masterful. Absolutely no critic from me to his work.
That said, many, many factors affect results. It's a near systemic thing (remember the butterfly causing the storm?).
Given a computer configuration (kind and number of CPU, amount of RAM and swap, disk latency/speed/seek times/etc.), I venture this is somewhat analogous to studying a factory throughput. IOW, seems to be a non-linear thing, if I'm not confusing terms here.
There's a guy, Eliyahu Goldratt, who has been giving consulting about a "Theory of Constraints". His most famous book is called "The Goal", written in fiction style and good reading, de per se.
But you don't get the idea until you see some simulations he/his company has. Basically, you can tweak a system (factory or computer) by changing parameters and see what changes are accomplished.
Maybe we could use such beast to do some high-analysis... don't know, just an idea...
JFS results in my case("dumb" benchmark included)
I've been reading good thing about JFS and decided to try it on my spare 10G hard drive. Before each test I erased and created new partition with and used appropriate mkfs command to create jfs/reiser/ext3 file system.
I used reiserfs and extfs drivers included in stock 2.4.22 kernel. I downloaded latest JFS sources at that time (more than one week ago) and recompiled kernel.
test1: "time tar jxvf linux-2.4.21.tar.bz2" JFS(worst) reiser3(best) ext3 real 2m57.296s 0m48.341s 1m22.625s user 0m29.900s 0m30.470s 0m29.920s sys 0m3.140s 0m3.900s 0m3.240s test2: "time rm -r linux-2.4.21" JFS(worst) reiser3 ext3(best) real 1m48.794s 0m2.143s 0m0.627s user 0m0.060s 0m0.030s 0m0.010s sys 0m0.660s 0m0.880s 0m0.470s test3: "time cp /mnt/somewhere/700MBfile.bin /mnt/test_partition" (copy one large file from fast 80GB disk to 10GB test disk) JFS(worst) reiser3 ext3(best) real 4m29.414s 1m7.493s 0m58.911s user 0m0.170s 0m0.130s 0m0.080s sys 0m7.010s 0m7.800s 0m6.730sResults speak for themselves. With work I do as a desktop user (uncompressing, compiling, and deleting large source trees and doing some multimedia stuff) JFS might be wrong choice. I'm using reiserfs and I'm quite satisfied with it.
regards
Keep in mind kernel versions...
Keep in mind all benchmark runs were done with the 2.6 kernel. The results will most definitely not be the same with the 2.4 series kernels.
That being said, ReiserFS v3 is known to not perform well with larger files, hence EXT3 being faster on your 3rd test. Overall though, ReiserFS v3 is a nice file system that I have no problem recommending.
Reliability Benchmarks ?
First off, micro-benchmarks like this are sort of silly. Something like page serving with apache, or e-mails sent/received with sendmail would provide far more useful real world information. Unfortunately this would take some time and skill to setup. So we'll probably see more of this filesystem "pissing contest" mentality in the future.
Also, it's noteworthy that in true linux zealot fashion, reliability of the filesystems was not mentioned. This is obviously not an issue for doing little toy benchmarking, but those of us in the real world have real problems when filesystems randomly corrupt data.
You can talk the talk
Ever hear of "isolating the variables?"
These numbers are actually very useful. It is true that they show nothing more than how the filesystems responded to the benchmark programs. However, an experienced observer can infer from them the abilities and disabilities of each filesystem, especially as compared to one another. Tests don't have to be real-world for them to be useful.
The kind of testing you propose would be absurd. It would take many man-months just to set up enough configurations to provide statistically-relevant data isolating filesystem performance. Incomplete testing would include so many other variables that nobody could infer much of anything.
if you're volunteering to do some exhaustive testing, don't let me stop you. Until then, benchmarks do provide useful results.
SCSI vs. IDE
Do these tests involve one-file-at-a-time throughput, or parallel access from multiple processes?
If the former, then SCSI is unlikely to perform a whole lot better than IDE (the 20% for 5x the price); if the latter, then I need to find the article again that demonstrated that SCSI can be up to 10x faster than IDE (which is supported by my own subjective experience).
Again, it matters exactly what you do with your system. SCSI is a waste if all you do is play games, surf the web, and listen to some music, but it has value in servers and systems under heavy I/O load.
Why I use ext2 at home
For home user, why use a journaling filesystem at all? The delay in rebooting after a crash (how often does this happen, anyway?) is not important when no one except you is inconvenienced by downtime.
Noise levels to me are important and I want my harddrive to spin down when not in use. Unfortunately, the only utility I know that does this - noflushd - does not work with any journaling filesytem.
ext2
You must not keep anything valuable. If your hd crashes what do you do? Buy a new one?
If noise levels matter to you
If noise levels matter to you, buy a Seagate Barracuda. They're stunningly quiet. Then you can use whatever filesystem you want.
ext2 is a pig for power outag
ext2 is a pig for power outages, when your HDD loses data it corrupts itself. I had a 2.5GB drive "die" - it seemed to keep corrupting data even after installing ext3 and then it lost libc6 so linux wouldn't boot. But even a non-destructive read/write test doesn't bring up any bad sectors so I dunno!
Corruption is a bitch, and I don't believe server hard drives should be spinning down. If the noise is bothersome get a barracuda or stick the machine in a cupboard.