Slashdot Mirror
Linux 2.4.5 Tested With Six Filesystems
Denis Lackovic writes: "we tested kernel 2.4.5 with six filesystems:
ext2, ext3, jfs, reiserfs, vfat, and xfs. You can find out the results here." The tests cover a number of situations, on decent but reasonable hardware.
You are an idiot. Ext3 is junk, slower than ext2, and tried to take a backwards-compatible approach to journaling, when this is one instance where you SHOULD be reinventing the wheel. Until I see something better than ReiserFS in the official kernel, then I'll give it a try.
don't know much about how unix style VMs operate eh?
This test puts essentially no stress on the broken parts of the 2.4.5 VM (which are mostly in the swap and victim page selection areas). The only part of the VM getting stressed here is the readahead and dirty buffer flushing code. Both of which work quite well at the moment.
More likely than not, the machine didn't hit swap at all (or very very little; the 2.4 VM will sometimes preemptively swap out very old pages to make more room for the page cache).
vmstat results during the test would tell us more, of course.
"The deletes are a different story. ext3 and reiser are quite a bit slower than jfs and xfs."
This is the exact opposite of my experience (with XFS and reiser).
Deletes on reiserfs are dangerously fast (no time to ctrl-c that accidental rm -rf). XFS deletes are painfully slow; I've noticed this on both IRIX and Linux.
I've no experience with ext3 or jfs.
Just FYI, we're currently doing extensive stability testing of ext3 and getting good results. Part of the reason that ext3 is still considered beta is that Stephen is a perfectionist -- which doesn't bother me in the least! :-)
-- "Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories?"
The copying times are real close so that shouldn't make much of a difference. Same with the reading.
The deletes are a different story. ext3 and reiser are quite a bit slower than jfs and xfs.
xfs and ext3 are pretty fast for writing.
So, I come to a different conclusion than the article does. For best all around performance, use xfs.
Now, which one of all these is considered to be the most stable? All the performance in the world won't matter if the code hasn't matured to a point where files won't be scrambled.
If tits were wings it'd be flying around.
Well then maybe the Linux VM isn't like other UNIX VMs. That's why it's broken ;-)
I have seen Linux go into heavy swapping when copying a large file. I have seen kswapd processor utilisation go through the roof when copying large files.
So there is stress on the broken parts of the 2.4.5 kernel. Maybe it decides not to swap, but that decision takes an awfull lot of time to make.
This is your sig. There are thousands more, but this one is yours.
Maybe. Unfortunately, this is only the beginning of a test. Who cares what the spead for writes, reads, and deletes are? The important things build on that. Examples:
When serving an NFS or SMB share, which filesystem performs best? In a shop with digital graphics files >100 MB? In a law office with files 100kb?
When used as a web server, with lots of static content? With dynamic content using Oracle? mySQL?
It's nice enough, but does it tell us anything other than (again, for example) the number of MFLOPS for a given CPU?
Heck, maybe not even that much.
Jesus was all right but his disciples were thick and ordinary. -John Lennon
There's one major problem with these tests: they used the 2.4.5 kernel. There are many known VM issues with these release. In fact, the VM subsystem is just plain BROKEN. The swap/cache paging is completely out of whack and sends swap through the roof, not to mention horrid performance on any intensive activities. High performance disk testing certainly falls under this category. This would explain why the XFS results were so poor compared to their previously reported results, as well as why the ReiserFS scores don't match every other benchmark that's been published to date. I'm sure that if the same tests were repeated with the 2.4.6 kernel (which includes major VM fixes as well as a few ReiserFS cleanups) we'd see some surprisingly different results, most of which would more closely match the ReiserFS scores that have been posted in the past.
Interested in open source engine management for your Subaru?
OK, let's see here.
1) VFAT sucks. Don't use it ever. No surprise.
2) JFS sucks on Linux. No surprise--it'll take a while and more development than they've put in so far.
3) EXT2 sucks because it isn't journalling, although it has quite good performance.
4) XFS doesn't suck, but it's not great.
5) Reiserfs doesn't suck, but it's not much better than XFS.
6) EXT3 doesn't suck, but it's still not out of beta!
Conclusion: I want EXT3 to become stable released code!
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban