Benchmarking Linux Filesystems Part II 255
Anonymous Coward writes "Linux Gazette has a new filesystem benchmarking article, this time using the 2.6 kernel and showing ReiserFS v4. The second round of benchmarks include both the metrics from the first filesystem benchmark and the second in two matrices." From the article: "Instead of a Western Digital 250GB and Promise ATA/100 controller, I am now using a Seagate 400GB and Maxtor ATA/133 Promise controller. The physical machine remains the same, there is an additional 664MB of swap and I am now running Debian Etch. In the previous article, I was running Slackware 9.1 with custom compiled filesystem utilities. I've added a small section in the beginning that shows the filesystem creation and mount time, I've also added a graph showing these new benchmarks." We reported on the original benchmarks in the first half of last year.
Very interesting article... (Score:5, Interesting)
Hardware mismatch (Score:5, Interesting)
Here's what's missing (Score:5, Interesting)
Something's up (Score:1, Interesting)
I'll leave aside the fact that all the other benchmarks I've seen are very favourable to Reiser4 and this is very unfavourable, and concentrate on the discrepancies.
Reiser4 is the slowest in searching, creating and removing. It performs a lot better when tarring and untarring, which indicates that reading and writing is much better than other filesystems. However, when you get to copying and creating large files, it loses again.
Why the discrepancy? These benchmarks contradict others, but don't make sense when taken alone. I'm inclined to believe the other benchmarks.
Re:I would agree (Score:5, Interesting)
There is the classic example from the Reiser website. If your password file gets hacked, you have to ditch the whole file if you're using traditional file systems. You only know whether or not the file's been changed. However, with the Reiser system, it can tell you *what line*, and thus which user/password, was changed.
That's just a taste of where you can go with the ReiserFS. There are other things coming down the pipe; check out the reiser website for a better idea of the new features that ReiserFS promises.
I think trying on a P2 266 is a bad idea (Score:5, Interesting)
For a decent benchmark of how filesystems work on modern hardware: use modern hardware.
Re:Very interesting article... (Score:3, Interesting)
If you're actually using that disk, still, have a look at it with smartctl. In particular, run "smartctl -t long" on it, and have a look at the results. If it doesn't pass that, don't even think of trusting it with your data.
Re:Very interesting article... (Score:3, Interesting)
I'd look through the Namesys page, but it's large and the TOC didn't reveal any warnings.. or I wasn't looking hard enough.
Re:I would agree (Score:3, Interesting)
Reiser4 now defaults to journalling everything - file data as well as metadata. If they left it like that, then no wonder it's slower - but it's the best choice if data integrity is important.
Nice stats... but wrong... (Score:4, Interesting)
What am I saying? I want to know how efficent these filesystems are in packing the data on the HD.
I'm glad that you get more data out of Reiser v4, JFS, and XFS at formatting time, but my feeling is that Reiser v4 (once profiled, tweaked and refined for speed and space) will pack data tighter than anyone else. Meanwhile, I'm looking for something like ext3 that packs better.
Interesting? How about a DECENT one? (Score:5, Interesting)
OK, so ext3 is not the fastest filesystem on earth. But it has some default options which makes it suck even more than it usually do, and those options are *documented* in Documentation/filesystem/ext3.txt
* Ext3 does a sync() every 5 seconds. This is because ext3 developers are paranoid about your data and prefers to care about your data than win on benchmarks. Syncing every 5 seconds ensures you don't lose more than 5 seconds of work but it hurts on benchmarks. Other filesystems don't do it, if you are doing a FAIR comparison override the default with the "commit" mount option
* ext3's default journaling mode is slower than those from XFS, JFS or reiserfs, because it's safer. When ext3 is going to write some metadata to the journal, it takes care of writting to the disk the data associated to that metadata. XFS and JFS journaling modes do *not* care about this, neither they should, journaling was designed to keep filesystem integrity intact, not data, ext3 does it as an "extra", and it's slower because of that. But if you want to do a fair comparison, you should use the "data=writeback" mount option, which makes ext3 behave like xfs and jfs WRT to journaling. Reiserfs default journaling mode is like XFS/JFS, but you can make it behave like the ext3 default option with "data=ordered"
ext3 is not going to beat the other by using those mount options, but it won't suck so much, and the comparison will be more fair. And remember: ext3 tradeoffs data integrity for speed. There's nothing wrong with XFS and JFS, but _I_ use ext3.
JFS ... (Score:3, Interesting)
Re:Warning (Score:3, Interesting)
ext3 and reiser at least let you fsck read-only mounted filesystems.
I brought up this problem to xfs developers and their response was "well, it's not a problem on SGIs so we're not going to fix it". Nice.
XFS - UPS = Disaster (Score:3, Interesting)
I have a strong warning if you are considering XFS. If you don't have a GOOD power backup (UPS), then don't use it. XFS caches very agressively for writes in RAM. You lose power, you lose that data.
XFS was designed with datacenters with good power backups in place, not home users. So chose carefully.
Re:Normalized results (Score:2, Interesting)
While I basically agree with you, 500MHz is not four times slower than 2 GHz. However in this case it is probably worse, since a 500MHz PIII implies a slow 100MHz side bus, slow 33MHz PCI bus, slow PC100 memory. A terrible system for doing benchmarks in 2006! It is completely unrepresentative of anything.
Actually, I am getting angrier as I write this. It was just wrong to publish an article using such an outdated system. People worried about high FS performance are not going to be using anything like that.
Re:Interesting? How about a DECENT one? (Score:2, Interesting)
touch files - slowest
find files - fastest
remove files - fastest
make directories - slowest
find directories - second best
remove directories - best
copy tarball to cur disk - middle of the pack
copy tarrball to other disk - middle of the pack
untar kernel - fastest
tar kernel - second best
remove kernel sources - fastest
copy tarball - fastest
create 1GB file - fastest
copy 1GB file - fastest
spilt 100MB - fastest
copy kernel sources - fastest
cat to
Based on this, I'd say ext2/3 is doing exceedingly well overall (if not the best!). So, what am I missing ?
Re:I would agree (Score:3, Interesting)
Any time I've lost a drive to data corruption it was formatted Reiser, every attempt at using Reiser eventually resulted in massive data corruption. This was various hardware and distros. I don't know about the newest version but trice bitten forever XFS for me.
Moving from ReiserV4 to JFS (Score:1, Interesting)
Based on the new benchmarks, I'm serious considering moving to JFS. It seems to be much faster for my typical desktop usage.
I'm curious what hash function he was using with ReiserV4, though. TEA produces a more responsive filesystem, for me, than R5. Reiser defaults to R5, so I'm guessing he was using that, but I'd like to see the difference that TEA produces.
Re:XFS - UPS = Disaster (Score:3, Interesting)
Anyway, for anybody interested, the results are at: http://staff.vbi.vt.edu/dom/iscsi/testing [vt.edu]