Slashdot Mirror
Linux File System Shootout
IpSo_ writes "Finally an extensive, human readable Linux file system benchmark has been unleashed upon us. Originally posted on the Linux Kernel mailing list, using two of the most popular benchmarking tools available, it compares all the major file systems, including their different mount options. The results are surprising."
Green is good (fastest) and red is bad (slowest)
HTH
My poetry site welcomes the unusual.
There is have focus on throughput in these benchmarks. Reading and writing lots of data, seeking in files and reading data, etc.
Notably missing are more day-to-day useful operations such as the creation and deletion of lots of files, parallel action on many open files,
lots of files in a directory, etc.
When I want to select a filesystem, I do not want to know how fast it can read a 3GB file sequentially. I want to know how well it performs on a fileserver, mailserver etc.
Still, they are interesting in showing areas of performance where something is a bit amiss.
It would be nice if exactly what they did was explained. You know, things like how you can get both the lowest total elapsed time and the worst overall score on one of the runs (because of CPU usage? ), what task was measured by each of the numbers printed, what the different settings on the different runs mean.....
Sigh, time to go read the source code for them.
The human readable result is you need to know what you want. There is no silver bullet.
It looks like xfs wipes the floor for all but temporary (loads of create/delete) file usage. Jfs looks like the best all-rounder. Reiser looks like something that can be tuned to the specific usage, but eats CPU for breakfast, lunch and dinner and EXT3 "surprise, surprise" sucks rocks. The other "surprise, surprise" is that EXT2 is still very good for many uses.
Frankly, I do not see anything new and fascinating in the results, but they are good to throw at people who keep asking me "why not EXT3" and "Why XFS or EXT2". Here is why!
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
I see that JFS won in the bonnie test, but EXT2 put up one hell of a fight and won the other roundup. I didnt think EXT2 was a journaling file system. Is it fair to thow in a Non Journaling FS in a benchmark against a bunch of Journaling ones? If it isnt journaling, then I gess Im going with JFS.
If I am wrong, please either resopond to correct me or email me.
scythefwd@yahoo.com
Stop signs are only Suggestions
I'm not trying to be an asshole or a troll; just hear me out.
I love Reiser. I also love Gentoo and adore Debian. Myself and another guy, Joe, are the main "linux geeks" in our computer group (cugy.net). When it came time to decide what to support at our group, we had to choose RedHat.
If I'm in a message board or IRC channel, I need to know some things about the guy I'm helping. We reccomend RedHat because that is the biggest US company behind Linux (IBM and SUN notwithstanding). If I am teaching people about Linux, then it is to both our advantages to teach/learn about what we will see "in the field". Therefore, we only support RedHat.
What does this have to do with anything? Well, RedHat 9 and Severn do not allow the creation of Reiser by default. I could probably boot from a Gentoo disk and format a partition to Reiser, then install RedHat to it. But, by default, only ext* is allowed.
I love to do things that improve performance. I love testing new things on my laptop or on a offline box in our test lab. But unless RedHat offers it, it will remain in the shadows of the linux world, which is, in turn, in the shadows of the user enclave. Hell, of every important box on my network, they are either RedHat or Win2k.
More on topic, Joe got a lot of recognition when the "internet got a lot faster". Did he upgrade the firewall? Did he install another OC-3? Maybe he reconfigured services on the proxy?
Nope, he installed a hard drive, formatted it to Reiser, and moved the proxy cache to the reiser disk. I couldn't belive it. Just changing the filesystem caused an increase that was noticable across our network. At no cost!
Good work, Joe.
I'd rather you do it wrong, than for me to have to do it at all.
Outperforms all the others, might be a bit over the top. If you look at the numbers, it really doesn't outperform any of the others. It is a good one, in the top ranges, but considering the fact that the outperforming fields are green and not red...
The site where: "I'm right, as long as you ignore the things that prove me wrong", became a valid method of debate.
What the author of the post you replied, probably meant, was that if the performance of a certain filesystem with samba is in a lot of cases more important than the performance of the file system pur sang, because lots of linux fileservers must be connected with window clients.
;-)
Anyway, the same accounts for DB-servers, etc. etc.
Please think before you flame
One thing that is even more important then benchmarks is the stability of the system...
I was once a very happy user of ReiserFS until the day the system kept on crashing when trying to start Mozilla...
It turned out the ReiserFS was corrupt and a rebuild of the tree was, well, not totally ok. Some of my files are corrupt still, but at least the system is running...
Does anyone have some good ideas on what filesystem is the most stable/best to reconstruct when things go FUBAR ?
One thing which would certainly improve the performance in these tests would be to use hardware which isn't completely outdated. They tested on a Pentium II (with matching outdated board and chipset) and a 6.4 GB harddisk. And I was wondering how no filesystem managed to move more than 15 MB/s... Come on, a low-end machine may make the differences easier to measure, but do you really want to produce the image that Linux filesystems can't move data at today's speeds? At least put abbreviated specs on the results pages.
worst: reiser4/reiser4_extents
You might think that just based on the amount of red in Reiser4's row, but if you look all the way over to the right, you'll notice something interesting: Reiser4 often completes the benchmark in significantly less time than the other filesystems. Reiser seems to be caching a lot of flak for the CPU usage (certainly it gets a lot of red boxes in this benchmark because of it). Personally, though, I've got CPU to spare. Disk seek times aren't changing drastically anytime soon, unlike CPU speeds. If I can trade some CPU cycles for less wasted disk seek time, I think that's a great trade.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
Filesystem benchmarks can be remarkably inconsistent. These tables do not display average difference between runs. Usually this means that the methodology used to do the benchmarking is lax, and thus, untrustworthy.
For example, consider that harddrives do their own error correction. Depending on the location of marginal blocks on the media, different file systems can score dramatically for no other reason than the drive's re-mapping or error correction logic is kicking in at a bad point. Alignment of data can also be a factor in performace which depending on the formatting procedure may be completely random when compared to the file system sitting on top of it.
For these reasons and a host of others, it is not reliable to do filesystem performance comparison on a single machine.
Bottom line is that there is a good chance that these data are not fair representations of the relative merits of each filesystem.
Why do the benchmarks seem to be completely opposed to the other. The bonnie says reiser4 is faster, and the iozone says jfs is faster, and reiser is the slowest. This isn't making a great deal of sense to me.
eally? You must be looking at a different set of benchmarks to me, because as I see it
So much for the "human readable" aspect of these benchmarks. Everyone seems to be walking away with a different idea of what the results are supposed to be showing.
Since there was no legend explaining what the colors meant, I couldn't figure out anything from looking at them. Is the high number good? As in did the most work? Or is the high number bad? As in took the longest amount of time to do something?
The other "surprise, surprise" is that EXT2 is still very good for many uses. /boot, /opt, /lib, and /usr that hold programs and are not changed often.
/usr and /var beside the swap so the heads didn't have to move to far to get to them ect.
especialy if the file system can be mounted read-only; you could do this in partitions like
I wonder if the kernal version makes a difference, are the xfs and jfs better on the 2.6 as compared to say the 2.4.19 that I'm running now; or how about with files that are much smaller like on the typical web server?
also partioning schemes can make a big difference in overall performance, in the old days i placed the swap partition in the center of the disk (most accessed in the center where the heads are most likely to be) the next most likely like
also does the disk make a difference, such as is any performance differences consistant between scsi and ide drives?
These are things that need to be looked at before make a decision as to which is best, but it definately appears that we need to do some looking now
Apocalypse Cancelled, Sorry, No Ticket Refunds
I think you are missing the point. In any test (especially one that is going to come in under scrutiny) all information about the target for the test should be published. There is no information about the OS (other than its Linux), what running software, what tweaks have been applied, etc. Based on what little information is provided, I doubt if anyone could duplicate the results. And the information should be available so that it can be tested independently. Everybody complains about benchmarks, but few actually put up any useful information other than the results. Hardly scientific.
If 30 33.3MB files (bonnie test) are not representative of your needs, please download the scripts. You can then modify the parameters for thousands of 2k files and post the results. Lots of people would be intersted, you know.
Friends don't help friends install M$ junk.
Well, when they say "human readable", they mean humans who will know what the stats mean... if you have no idea what these tables are showing you (I find that reading the headings of each column works quite well), then what use do you have for them? and further, why do you care?
Exactly,
I'm also very interested in the ease and ability to repair (or auto-heal) a corrupted file system after a hard crash.
Also, simple undelete would also be on my wish list. just in case.
Anyone here who's got those features ready?
Why are other peoples sig's always more witty ???
The question is, I think, does CPU load for non-disk-IO related tasks tend to increase when disk IO tends to increase. Is there a correlation? I would argue against it. Typically programs fetch data, and THEN perform operations with it. IMHO, in order to derive a cpu load/disk load correlation, you would apparently have to be doing LOTS of SMALL disk IO while simultaneously using lots of CPU. I don't think many programs operate this way. Many programs access lots of disk in small pieces, and many programs are CPU-bottlenecks, but I don't think the intersection set is all that large (if you are reading tiny amounts of data, you can't possibly being doing THAT much processing on the data right?).
Furthermore, the question becomes "is the CPU usage amortized as filesystem functionality increases". I think this is EXACTLY what we are seeing. Logic is being offloaded from individual applications and bundled into the filesystem (at least with Reiser), as more applications require more sophisticated and database-like filesystems. I think this trend will increase, and we will see more "smart" filesystems being used as databases, and less "dumb-but-fast" filesystems. Sure, applications which don't specifically use the new sophisticated features of the filesystem will see the hit, but I'd wager applications that DO use the new features would actually see a net CPU usage drop, not increase. One immediate example I see is security/ACLs and how they can be embedded in Reiser.
It's 10 PM. Do you know if you're un-American?
Don't count on this. The write (and maybe read) drivers will always be "experimental." Why?
Because NTFS specs are locked in a dark closet in near Seattle never to be seen by the evil Linux developers. These developers, fearing for their lives, will never have the guts to deem their NTFS write stable - there will always be a slight chance you'll corrupt your entire disk table - and no one wants their so-called "stable" driver to corrupt people's data.
In NT4, NTFS was at version 1.1, aka NTFS 4.0 (to align with NT4.0). In Windows 2000, it was version 3.0, aka NTFS 5. And in XP, it's version 3.1, also known as NTFS 5. The point is, NTFS is a moving target, so it's unlikely we'll see effective NTFS abilities in Linux anytime soon.