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."
speed is nice, but I think the more important question is; how stable is it?
The first item number is time, in seconds, to complete the test (lower
is better). The second number is CPU use percentage (lower is better).
reiser4 171.28s, 30%CPU (1.0000x time; 1.0x CPU)
reiserfs 302.53s, 16%CPU (1.7663x time; 0.53x CPU)
ext3 319.71s, 11%CPU (1.8666x time; 0.36x CPU)
xfs 429.79s, 13%CPU (2.5093x time; 0.43x CPU)
jfs 470.88s, 6%CPU (2.7492x time 0.20x CPU)
What's interesting:
* ext3's syncs tended to take the longest 10 seconds, except
* JFS took a whopping 38.18s on its final sync
* xfs used more CPU than ext3 but was slower than ext3
* reiser4 had highest throughput and most CPU usage
* jfs had lowest throughput and least CPU usage
* total performance of course depends on how IO or CPU bound your task is
There are other things about filesystems us sysadmins to know about. Which is the most stable and crashproof filesystem? Ive suspected it to be XFS from which I recovered data after doing dd if=/dev/zero of=/dev/hda1 count=2048576
Also what filesystem would require the lest or no syncing at all? Befs?
In server environements with stripped 15K cheetah SCSI drives, you'd worry more about stability than speed.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
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.
FYI, kerneltrap just moved to a new server (this week!). It used to be run on Jeremy's DSL line, which was why it would get shot to shit whenever it got slashdotted.
Now its in a colo on new (fast) hardware (paid for by users' donations), and upgraded to drupal 4.2 (faster here too).
So slashdot away!
-molo
Using your sig line to advertise for friends is lame.
And a number of people complained that it wasn't a great benchmark. Hans Reiser admitted it was just a quickie, and I forget who it was that said it, but ext3 has some performance enhancements that are on the cusp of merging into Linus' tree from the -mm kernels.
Wait until 2.6 is out folks. These numbers are still open for mass fluctuation.
Stability bugs will be fixed if the performance is good enough, but speed problems can be hard to fix without altering the most basic things about a filesystem.
I think for "Stability" you mean "Robustness", so that data loss can be avoided in a power outage or other out-of-spec situations (things supposed to be fixed with data journaling, atomic transactions, etc.), while I mean "lack of Bugs". It is true that robustness is a problem that should be figured out at design time and it can be more important than speed, but I think the original poster means unbugginess for stability. Anyway, reiser4, ext3 (ordered/data journaling mode) are robust enough, but the former is new and buggy.
Right, but they gave CPU % used, rather than the number of cycles used during the test - Reiser's CPU numbers looked higher *because* it was fast in terms of wall time.
With respect to filesystems and database performance. EXT3 came out on top.
"Thanks to the remote control I have the attention span of a gerbil."
30%-40% CPU Usage - whoa. What happens to poor me - with a PIII 550 MHz, 128 MB SDRAM and KDE running all the time.
I switched from RedHat to Gentoo and KDE stopped crawling. God knows what will happen with ReiserFS4.
Nandz.
Why do we need fast file systems? Or rather, why should we spend so much effort on performance differences of such small magnitude (take out reiser4 and its high cpu usage)? The only things I can think of are: swapping memory - this will really slow the system down, because disk is orders of magnitude slower than main memory; and databases that absolutely require high performance. But both of these typically *already* use custom file systems (or raw partitions) tailored to their exact needs. As normal user (somebody who is not constantly copying Mozilla source tries around), why should this matter? I can't remember the last time I thought "boy, this file access was slow, I wish I had a faster file system".
It's 10 PM. Do you know if you're un-American?
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 care about performance because I have a few hundred thousand files on servers that 100 employees need to access. Caching will only get you so far when you have a lot of people going after a lot of files through out the day. Since we have the choice of which fs to use, it is nice to have more info to pick between them.
There is more to this world than home users and databases.
If I have 2500 4k files in a directory, and my filesystem uses a stupid algorithm to store that information, it might take 2 or 3 times longer to retrieve a list of files than it does on a decent filesystem. When you've got a webmail frontend to your Maildir, and your webmail code has to grope through all directories, all files, even small differences are HUGE. Clever FS design will win the day.
I want to delete my account but Slashdot doesn't allow it.
how much RAM uses reiser4?
open4free
Unix traditionally doesn't support record locking for a portion of a file. For portability, this is best handled at the application (db engine) level.
As far as using the fs itself as a rudimentary hash, FreeDB does exactly that: the compact disk ID (along with some other stuff) forms the lookup key, which is used as the filename. The Postfix MTA also uses fs-based hashing, with the first two characters of the message queue ID being used also as a subdirectory and sub-subdirectory name, to help speed up directory searches.
One thing not mentioned in the kerneltrap discussion is the fact that JFS uses lazy allocation, and a complete dissociation of inum and block number. Under JFS, data space on disk isn't allocated until it's ready to be flushed from the buffer, which accounts for the 38 seconds of sync time at the end of the tests.
Greetings gentlebeings,
Since I recently reinstalled my Debian system, I decided to put some effort into implementing my filesystems right. I decided on XFS for various reasons, mainly that it has always been rock solid for me (I've had some problems with ReiserFS causing heavy data corruption -- it's a long time ago and they've undoubtedly improved the system since, but still I prefer XFS since I've never even once had a problem with it, and know nobody who has), and that its good large-file performance is more useful to me than Reiser's kickass small-file performance. Also EAs and ACLs are neat. What sucks about XFS is poor small-file performance and abysmal delete performance.
Anyways, I made a few bonnie++ runs and messed around with some of the many mkfs and mount options of XFS. In the end, my tweaked XFS filesystems beat ext3 (mode=ordered) for delete performance, which was a substantial improvement over a standard XFS mount.
I made a writeup about the whole procedure at Everything2. Go slashdot the poor bastards. Warning: The language is tailored to the fact that not all E2 users are geek hardcore.
Six sick
By having several file systems competing, the developers feel the stakes are higher and work harder to be the best. We also see a bit of differentiation, in that the different file systems typically are good at different things. In my experience, XFS is great for largish mysql databases, while ReiserFS does an excellent job on handling many, small files (like your /tmp).
So, as long as Linus only allows stable filesystems in the stable kernels, I'm all for file system innovations making their way into the kernel! Everyone don't need 'em, but some do!
Stop the brainwash