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)
The original article
I support the Center for Consumer Freedom
tests on popular Linux filesystes
So did the tests come back positive or negative? Systes are nasty things, and early detection is important to increase chances of survivability.
Remember kids. Test early, and test often. You files will thank you.
Karma: Chameleon (mostly due to the fact that you come and go).
EXT2 has better throughput
EXT3 has better file handling capablities
Reiser has better search ablity
XFS has better delete capablities
JFS may be a better choice in regards to file manipulation Subject to debate of course...
Maybe slashdot needs a filesystem update to one with more powerful meta-data support like something that can detect when the same URL has been used in more than one post within a certain time. Sheesh.
That is, before it melted.
You're right, that was a total surprise.
"Avoid employing unlucky people - throw half of the pile of CVs in the bin without reading them." -- David Brent
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?
I mean, really. "Mad about You" was a fine TV show... but this good?
How long until we see McKellenFS?
http://209.81.41.149/~jpiszcz/index.html
:)
it's not slashdotted yet
here is the winner. FAT 16
Obviously (as you point out) a journallying filesystem is what you need. I went for Ext3 on my Debian servers. I/O throughput wasn't so important. The good thing about Ext3 is its backwards-compatibility with Ext2. If there's a problem and you don't have all the kernel modules or tools then you're still pretty much guarranteed access to the file system by mounting it as Ext2 as support for that system is almost universal under Linux.
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?
It's slashdot's mob tactics again. Now Taco will call their ISP and ask them "Are you SURE you don't want our protection? Certainly protecting the servers you love is worth some...compensation." If they say no, another posting of this story as soon as the admins "forget" this one.
I've been using ReiserFS _EXCLUSIVELY_ since about 2.4.11 and I've never had a single problem. It's important to format with the defaults and not specify 'special' arguments to mkreiserfs or you can run into trouble.
I've got three systems currently running reiser on Gentoo, from my PowerPC/SCSI/NFS/Samba file/print server to the ancient Compaq laptop with a 4GB drive. I've never had as much as a hiccup from ReiserFS.
Under what circumstances did you lose data?
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
I've never understood why they don't move to ReiserFS, at least for new installations. With Fedora you have to use a kernel option to enable ReiserFS installation and with RHEL you can't install to a ReiserFS root, even the reiserfs kernel module is in their kernel-unsupported RPM which means don't call for help. I love RH but they need to get the ball rolling on this one!
No, in fact ext3 is one of the few that actually will journal data as well as metadata.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Here's a mirror of the article:l
http://www.gutenpress.org/links/LG/102/piszcz.htm
RFC2119
From FreeBSD, that is... Would be nice to see that compared to Linux' FS-es. As in this earlier benchmark (PDF).
In Soviet Washington the swamp drains you.
What was the reason for the panic? I've been running my system HARD for years without any panics.
If your hardware or kernel has problems you can hardly blame a filesystem that's expressly designed for high-reliability hardware for data loss.
'journalling' is not any better than none when it comes to flaky hardware or a badly compiled kernel. All it means is that you don't have to wait an hour for fsck to run. The whole point of a journalling FS is that it 'knows' what files are suspect after a major outage and it quarantines them, it's not any better at preventing them from being corrupted.
All in all, I can say that Linux an other Unices are VERY sensitive to improper halts/panics/shutdowns. I've hosed several OS X machines by not exiting gracefully, and several Linux boxes too. Your number-one priority when setting up a system is to do what it takes to keep it from crashing, ever.
When I built my desktop I carefully selected components that were 100% Linux-compatible so I wouldn't have issues like the ones you described.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
When you see bar graphs with two items its just plain silly.
Hey, he's management material! Quick promote him!
-- If god wanted me to have a sig, he'd have given me a sense of humor.
There are options, or settings, that you can do for ext3, the default is slower, but it saves your data. Ext3 not only journals metadata, like XFS, etc... but it also journals data, which is the only filesystem that does that, if I understand this correctly.
/etc/fstab and reboot, no big deal.
"data=writeback" mode does no data journaling, only metadata journaling, and you would probably see better performance here. Although, you could lose data in the event of a power outage (no fun). Same thing applies to XFS, JFS - you could lose data because only metadata is being journaled, not real data.
"data=ordered" mode - inbetween, still no data journalling, but there are provisions that make it less likely to lose data in the case of a power problem. It has something to do with the way it journals the metadata and the way the filesystem interacts with the disk that makes is a little slower than data=writeback but also a little more secure than data=writeback if you get a power outage.
"data=journal" mode - this journals data and metadata, and with the exception of a few situations, is the slowest. The least likely to lose your data, but also much slower.
I am assuming, or at least it looks like, these tests were run with the default data=journal - so to be fair, they should have been run in data=writeback, or maybe even all three modes. Again, all you have to is specify in
It would probably be better to compare the ext3 in data=writeback mode.
Lynx.
It doesn't support GIF either though.
Why is it that every benchmarking article contains the words "The results may surprise you?"
Have any of you ever been surprised?
Well, the simplest answer is that Stephen Tweedie is their filesystem guru, so why not use his baby in their OS. However, that's not the real answer. SCT is a clever guy, and mature enough to not let pride get in the way of the best possible system. (a similar question: Why does sun still use UFS?) For Redhat, EXT3 is probably the best general purpose filesystem, particularly for the root drive. Redhat is interested in selling on servers, where the root filesystem is not the bottleneck. You install the OS onto EXT3, which has decent performance and is very mature. Then you install your database / exported directories / mail spool / whatever onto the filesystem that is best for that job.
Ext3 is a very close cousin to Ext2, which has been around for a very long time, and changes very slowly. Reiser has grown and changed a LOT in the last three years, including some metadata changes that effect on-disk structures. Though it has stabalized lately, Redhat is correct to be cautious. XFS and JFS, though very mature filesystems on other OSes, have only recently become tightly integrated with the Linux kernel. Though technically controlled by the linux kernel community, all three of these other filesystems are really controlled by little cabals of people within IBM/SGI/ and then Hans Reiser. While these groups try to be transparent in their development process, Ext3 is very transparent in its development and direction.
One other tremendous advantage that Ext3 inherits from Ext2 is a fast, versatile, and effective fsck program. Journals are great in the event of power failures. However, they do not protect against Windows, or a faulty fibre channel driver, or uninformed sysadmin who accidently writes over the first 1 MB of the disk. Fsck.Ext2 is one of the best around.
I did a bunch of tests like this, but in 2.6 instead of 2.4. My conclusions:
* Ext2 is still overall the fastest but I think the margin is small enough that a journal is well worth it
* Ext3, ReiserFS, and XFS all perform similarly and almost up to ext2 except:
o XFS takes an abnormally long time to do a large rm even though it is very fast at a kernel `make clean`
o ReiserFS is significantly slower at the second make (from ccache)
* JFS is fairly slow overall
* Reiser4 is exceptionally fast at synthetic benchmarks like copying the system and untaring, but is very slow at the real-world debootstrap and kernel compiles.
* Though I didn't benchmark it, ReiserFS sometimes takes a second or two to mount and Reiser4 sometimes takes a second or two to unmount while all other filesystem's are instantaneous.
Whole thing available here
These days you could just use a second disk. It would be faster, too.
I wonder if there's some way for a RAID to constantly, dynamically optimize itself. After all, it's striped and redundant, there must be all kinds of funky tricks you can play to reorganize data on the fly...
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.
You can see benchmarks of it at www.namesys.com/benchmarks.html
oh no, all those people running IE 3 can't see png, better not use it.
Snowden and Manning are heroes.
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.
Sun uses UFS because it is still the best filesystem for a root filesystem.
A more interesting question is: Why do Linux zealots incessantly rag on UFS?