Forgot your password?
typodupeerror
Data Storage Software Linux

Benchmarking Linux Filesystems Part II 255

Posted by Zonk
from the some-of-this-content-may-be-inappropriate-for-young-readers dept.
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.
This discussion has been archived. No new comments can be posted.

Benchmarking Linux Filesystems Part II

Comments Filter:
  • by toofast (20646) * on Friday January 06, 2006 @01:36PM (#14410134) Homepage
    An interesting analysis in every aspect, and it's fine and dandy for the person who uses 400 GB drives and a ATA controller on a 500MHz computer but I'd like to see how the filesystems compare on a bigass RAID system run by a Power5 server, or a few Itaniums that usually have with a few hundred connected users. Something a bit more "entreprise" - where the choice of a filesystem is a bit more critical than a small server or a home PC.
  • Hardware mismatch (Score:5, Interesting)

    by lostlogic (831646) on Friday January 06, 2006 @01:52PM (#14410260) Homepage
    It is widely known that Reiser filesystems are heavy on CPU usage 4 more than 3. These benchmarks seem to show a CPU bound IO situation as opposed to an IO bound IO situation. As an earlier comment pointed out, the hardware used in this test was a 500mhz CPU. My slowest computer is a 1000mhz system, which is usually IO limited, not CPU limited. I'd be interested to see these same benchmarks run on real hardware, or some more complex benchmarks (random RW, DB load, etc.). The hardware used for this test would be suitable for a fileserver, but not much else. In that situation, E2, E3 or XFS are probably the right choices as it points out. What about desktop loads, enterprise loads, or something more interesting?
  • by CastrTroy (595695) on Friday January 06, 2006 @01:54PM (#14410279) Homepage
    Here's what's missing. They forgot to tell you how well the drive performed after being used for 1 year, and having constantly moved data from one place to another, and constantly deleting and creating new data. It would have been a better test if the drive was about 75% full, with data from 2 years of use, and then the same tests were performed.
  • Something's up (Score:1, Interesting)

    by Anonymous Coward on Friday January 06, 2006 @01:59PM (#14410327)

    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)

    by lawpoop (604919) on Friday January 06, 2006 @02:16PM (#14410450) Homepage Journal
    I'm no expert by any means, but I think the idea behind the ReiserFS is breaking down the FS paradigm from the file level to the line level.

    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.
  • by H4x0r Jim Duggan (757476) on Friday January 06, 2006 @02:18PM (#14410467) Homepage Journal
    Reiser is not designed for slow CPUs. AFAIK, a key part of the design was the Hans Reiser realised that CPUs were vastly underused. IO resources were maxed out and CPUs were sitting idle. So he found ways to use the CPU to make more efficient use of the IO resources. So this benchmark on a 500Mhz machine will of course show Reiser in a bad light, and moving lower down to a 266Mhz will make it even worse.

    For a decent benchmark of how filesystems work on modern hardware: use modern hardware.
  • by Captain Segfault (686912) on Friday January 06, 2006 @02:20PM (#14410489) Homepage Journal
    It is completely absurd for a filesystem to kill a disk. If you were getting those errors (with the "drive ready" and "seek complete" bits being set being most common) it *strongly* suggests that either your disk is broken or it is improperly powered.

    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.
  • by chrismcdirty (677039) on Friday January 06, 2006 @02:39PM (#14410665) Homepage
    'Kill' was a little strong for how I meant to use it. What I really meant to say (and can now find any data backing me up) is that Reiser4 deals with the disk so intensely that it uncovers flaws and errors that other filesystems may (A) never find, or (B) live with.

    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)

    by m50d (797211) on Friday January 06, 2006 @02:43PM (#14410701) Homepage Journal
    Reiser4: Surprisingly, I didn't see Reiser4 really shine at a whole lot in the benchmarks. The massive mount time tells me it needs to be a local drive that only needs mounting the once. Just not sure what sort of data would be best on it.

    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.

  • by strredwolf (532) on Friday January 06, 2006 @02:56PM (#14410806) Homepage Journal
    You know, I was looking at all these stats from this roundup... and while I'm glad they have one nice stat (how much the FS itself takes, the rest for space), I'm not happy that there is no "We've loaded it up, lets see how much is left" statistic.

    What am I saying? I want to know how efficent these filesystems are in packing the data on the HD.

    • I know Reiser v3 has "tail packing" to take small files and ends of files that stick out past a block boundary, and packing them inside "sub-blocks" to save space. ext2/3 is stuck at the block boundary (even though you can adjust the size of these blocks)
    • I don't know if ext2/3 has been enhanced to pack small files in inode data.
    • JFS and XFS does not have a tail-packing feature, and is too stuck at (adjustable) block boundaries.


    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.
  • by diegocgteleline.es (653730) on Friday January 06, 2006 @03:01PM (#14410842)
    I'm *sick* of reading filesystem benchmarks of people who doesn't even care about even reading the documentation of the filesystems they compare

    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)

    by Pegasus (13291) on Friday January 06, 2006 @03:11PM (#14410930) Homepage
    Of course JFS won, since it was designed to be as simple as possible ... it's originating from OS/2, afterall. On such a machine as used in this test, this is a huge advantage.
  • Re:Warning (Score:3, Interesting)

    by bani (467531) on Friday January 06, 2006 @03:39PM (#14411151)
    You can't fsck an xfs mounted filesystem, even if it's mounted read-only. If your root fs gets damaged and you need to fsck it, you need to boot from a rescue CD. If it's a server in a remote location, you're shit outta luck.

    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)

    by fire-eyes (522894) on Friday January 06, 2006 @03:41PM (#14411175) Homepage
    XFS is a nice filesystem, I like it. Not enough to use in production, but I like it. Personally I use reiserfs3.6 on many production servers, and have never seen a problem. I am experimenting with 4 at home.

    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.
  • by cecom (698048) on Friday January 06, 2006 @03:46PM (#14411218) Homepage Journal

    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.

  • by cecom (698048) on Friday January 06, 2006 @04:09PM (#14411419) Homepage Journal
    May be I am misinterpreting the data somehow, but from a quick look at the article EXT2/3 is performing quite well.

    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 /dev/null - middle of the pack

    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)

    by Shelled (81123) on Friday January 06, 2006 @04:13PM (#14411463)
    "Reiser4 ..... it's the best choice if data integrity is important."



    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.

  • by Anonymous Coward on Friday January 06, 2006 @07:23PM (#14413181)
    I've seen those benchmarks before, and last time I saw them, I decided Reiser was for me. I've been using it ever since.

    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.
  • by ananke (8417) on Friday January 06, 2006 @09:03PM (#14413990) Homepage
    Recently I've been doing some benchmarks to test iSCSI initiators on linux. So far [until 2.6.15], XFS is the only filesystem that got damaged after some kernel panics. On 2.6.15 I've damaged JFS almost everytime I got a kernel panic, very frigthening.

    Anyway, for anybody interested, the results are at: http://staff.vbi.vt.edu/dom/iscsi/testing [vt.edu]

Chemist who falls in acid is absorbed in work.

Working...