Slashdot Mirror
Linux Filesystems Benchmarked
smatt-man writes "Over at Linux Gazette they ran some tests on popular Linux filesystems (ext2, ext3, jfs, reiserfs, xfs) and the results may surprise you."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
And the reason is that you used jpegs. jpegs are for photographs; use gif for images such as this. The text won't end up unreadbly blurry and you'll save tons of disk space/bandwidth.
Do you have ESP?
While they do measure stuff like access times in ms, they don't mention recovery times (chkfs) that are mentioned in ms for reiserfs and mins for ext2. And they don't mention reinstallation times (measured in hours) which occurs for ext2 a lot more than the journalling filesystems :-)
Cyde Weys Musings - Scrutinizing the inscrutable
Personally I could care less which file system is fastest. The most important aspect to a file system is how stable it is with my important data. All the speed in the world means absolutely nothing if the file system is not stable. EXT 3 has never ever let me down so I intend to stick with it, at least until RedHat releases their version of GFS.
Got Code?
Also, it's mountable from FreeBSD. Reiser, XFS and JFS are not.
This may seem trivial until you have a dual boot system with FreeBSD and GNU/Linux and you want to transfer your /home dir or whatever.
-JemWhy is it that every benchmarking article contains the words "The results may surprise you?"
Have any of you ever been surprised?
If you are using IDE drives with the write cache enabled, then NO journaling file system is safe on your system. This is because IDE drives with write cache respond immediately to requests for fsync with true, whether they've written the data out or not.
If your data is important, either turn off the cache on your IDE drive or buy a SCSI drive, which won't lie about fsync. This is a problem for both linux and BSD.
Later model IDE drivers and drives may be able to work properly with cache enabled, but not now. There are ongoing discussions on BOTH kernel hackers lists, BSD and Linux, about what to do, and no solution in sight.
--- It is not the things we do which we regret the most, but the things which we don't do.
No mention of data=writeback, or any other optimisation tweaks, however. Kinda sad. The article is nice, the graphs are.... Err too much of a good thing?
And basically the results just reiterate the design imperatives of each filesystem(how unsurprising!)
- ext2 predates them all
- ext3 is a low-impact, let's reuse what we know as much as possible, kinda file system
- reiser's b-trees reflect it's "once we put the data in, how do we find it again" orientation
- XFS was at least at one point, designed for "Media" files(think renderfarms), aka LARGE files, much of the benchmarks it won were on such files, although its design was also influenced by large-scale server needs(a renderfarm is a large-scale server cluster right?)
- JFS was influenced by large-scale server needs(databases), but tampered by OS/2's needs, and other systems, resulting in a filesystem that's a bit more nimble than XFS, but less handy with huge files(normal, since databases try to use raw-io if necessary on huge files, unlike render clusters)
I think this demonstrates the implications of early design imperatives on long-term software trends. XFS and JFS were developed for other platforms and ported to linux, yet notice how they can't really change their strengths(good thing too!).
Anyone try the same benchmark on the 2.6 kernel just to contrast it? Wouldn't the new IO-system help to mitigate those weird ext2/ext3 slowdowns the article mentions, but doesn't explain?
Wow...I'm really surprised that I don't see anyone else around here bashing this "benchmarking" as totally ridiculous. Get it together, people! I mean, how does a group of folks that typically pride themselves on shredding the foolish articles that come by miss these beauties:
1) This guy goes out with the stated goal of evaluating real-world performance...so he starts by throwing out all real benchmarks. Of course, those tools are designed by experts to try to represent real-world performance, but who cares, right? Instead, our jackass throws together a bundle of random operations and times them. No thought is apparent in the choices of the operations, and no discussion is given as to why the choices were made.
2) The conclusions are drawn by simply adding the times of all the tests together. If you haven't figured out why this is dumb as a rock, let me explain: test #1 took 23-40 seconds, while test #2 took .02-.04 seconds. So, in his conclusion, test #1 was weighted 1000 times as heavily as test #2. I don't know about you all, but I for one don't feel that touching speed is 1000 times as important as finding speed.
3) Even if he had normalized all the times so that the mean in each test was the same and then added those, he would still be wrong...various tests ought to be weighed differently, because real-world usage doesn't do all of these things the same amount. That said, the weight given to the tests needs to be well thought out and planned, rather than arbitrarily assigned (accidentally) without paying any attention. Interestingly enough, this sort of purposeful weighing of tests is exactly the sort of thing done by the real benchmarking tools that this idiot threw away.
4) Perhaps this one isn't as important...but this guy can't make a graph to save his life. Half the bar graphs put time on X and the other half put time on Y. Graphs that obviously should be bar graphs are made into dot-line ones. The text is blurry and you can't tell the colors in the key.
Anyway, I still don't get why everybody around here seems to have missed all this...it was painfully obvious to me when I just took a cursory glance at it.
Given a choice between free speech and free beer, most people will take the beer.