Slashdot Mirror

← Back to Stories (view on slashdot.org)

Performance of Ext2, ReiserFS, and XFS?

Posted by Cliff on from the interpreting-the-numbers dept.

3141592654 asks: "I've been doing a little experiement to compare Ext2, ReiserFS, and SGI XFS. The experiment (LFS Sprite benchmark for small files) involves tight loops of creating 10,000 1K files spread equally among 100 directories, reading them back in order, and deleting them. On a 1GHz processor with plenty of RAM running Linux 2.4.2, with matching versions of file systems in default configurations (no debugging and no internal checks). In our tests, EXT2 turned out to be faster than both ReiserFS and XFS. We had been led to believe by other published results that XFS would be much faster than Ext2, and ReiserFS would run just about as fast. Have any slashdot readers had experienced similar results with these filesystems? Or have we simply overlooked a major factor in our tests?"

"Here are the results (create, read, delete) in seconds:

  1. Ext2 (0.45, 0.093, 0.13)
  2. ReiserFS (2.5, 0.45, 0.94)
  3. XFS (6.4, 0.15, 7.1)

Note that ReiserFS (v3.6.25) and XFS (v1.0) are vastly slower than Ext2 (v0.5b) in an identical configuration.

Since we can obtain these numbers consistently, we are wondering why they deviate from various published results. We have ruled out cache warm-up and disk-zone effects. All three file systems were set up from scratch from a 6 GB disk partition."

12 of 38 comments (clear)

  1. A test is not a test is a test.... by pwagland · · Score: 3, Insightful

    Try running the same test, but with the following changes:

    10000 1K files spread evenly over (10|1) director(ies|y).

    For small files in particular (and 1K is pretty small...) the also try telling us what the value of the -notails is on your Reiserfs mount.

    Both XFS and Reiserfs are more complex, but they have a tendency to "scale" better. This scaling is primarily in the directory sizes, but also counts in filesystem sizes as well.

    They have different design goals. Try adding this to your test:
    Add files, delete them, type sync and hard poweroff the machine. How long does it take to reboot? Now try this with 20Gb and 100Gb filesystems.

    To some extent for a test of the type that you are performing, you would expect them all to perform roughly the same. You have not seen that, however...

    Remember the cardinal rule in testing: One test does not a benchmark make!

  2. Why the world spins... by autocracy · · Score: 3, Interesting
    Ext2 (0.45, 0.093, 0.13)
    ReiserFS (2.5, 0.45, 0.94)
    XFS (6.4, 0.15, 7.1)

    Hmmm, seems to me that the more time it spends on writes, the faster it reads... Notice a slight trend? Now, unplug the power. See which one comes up faster. No benchmark needed - you DON'T want to sit through a fsck run. Also, longer writes are a result of better indexing. Better indexing = bad ass read times, and in respectable proportion. (Of course, XFS COULD work on that delete time...)

    --
    SIG: HUP
    1. Re:Why the world spins... by pete-classic · · Score: 2

      Uh, did you miss the zero in the tenths place on ext2? It has the lowest write AND read time.

      So, to answer your question directly, yes, I see a trend, ext2 is fastest in all three areas.

      -Peter

    2. Re:Why the world spins... by ahknight · · Score: 2

      ... except for booting after a power failure. While you're fscking your fscked up drive I'm at a login prompt with all my servers running with all their data (Reiser). ext2 is great ... for the /tmp dir and any other directory that need be quick and somewhat reliable. But for /home and /usr (and others) you want a stable and smart filesystem, without regard to how quickly you can delete 10K files on it.

    3. Re:Why the world spins... by autocracy · · Score: 2

      heh, working off of ouside knowledge. From experience and benchmarks from other sources (hehe, I feel dumb right now for missing that), I can tell you that real-world, Reiser beats Ext2, and benchmark overall. Can't speak real-world for XFS, but benchmarks from some really sweeet machines say it's a good thing (tm).

      --
      SIG: HUP
  3. Scalability by Outland+Traveller · · Score: 2

    I know the article is more about performance, but I have to point out that the reason I'm using XFS right now is scalability. It is *VERY NICE* to be able to create files greater than 2GB on a 32bit CPU, among other things.

    As for performance.. the test was for "lots of little tiny files". ReiserFS is supposed to be the champ at this. XFS is tuned for larger sizes on larger sized filesystems. It has support for guaranteed-bandwidth (realtime support), ACLs, and as the ginsu-knife salesman says- "and much, much more!".

    One other thing worth mentioning is that XFS comes with mature userland tools.

  4. FS tests by blakestah · · Score: 2

    The majority of the "real world" tests I have seen show that IF ext2 or ext3 has a deficit compared to XFS or ReiserFS, it is a REALLY small deficit.

    People will say XFS scales better, but ext2/ext3 is limited in scalability only by the VFS layer which also limits XFS.

    About the only real deficit with ext2/ext3 is lots of small files in one directory, but there is a directory hash patch from Daniel Phillips that fixes that - and will be included in 2.5.

    The reality is that for the vast majority of users it will not make a difference which journalled file system they use. And if you have an application that depends heavily on the file system, bench your application on the different file systems. You will get an answer specific to you - and that is what matters to you.

    Backup tools, which have little to do with performance, can also be important. Variants of dump exist for xfs and ext2/ext3, but not ReiserFS. Tar works for all of them.

  5. Something fishy by hardave · · Score: 5, Insightful

    Personally I don't trust filesystem benchmarks where the test data is less than the amount of RAM in the box. 10,000 * 1K = 10MB which I'm assuming is less than the amount of RAM in the tests. At that point you're not taking into account interaction with the disks, all the reads and writes are occuring in filesystem cache.

    The other week I ran some bonnie tests using a dual 1GHz, 1GB, 18GB 15K Seagate disk, 2.4.10. Default filesystem create options for both Ext2 and Reiser and 2000MB test file. I saw almost equal results with both filesystems averageing around 50MB/s for both reads and writes.

    1. Re:Something fishy by kijiki · · Score: 3, Informative

      You've nailed it. Its odd your post is still hanging around at Score: 1 even though its the only one that correctly explains the glaring flaw in the benchmark.

      ext2 does no journalling, so all 10 megs of your writes were buffered into ram. The benchmark then returned done, even thought little or no data had reached the disk yet.

      The journalling filesystems do the same thing, with one major exception. The metadata changes MUST be written to the journal before the benchmark returns done. The data can stay in memory, since XFS and reiserfs only do metadata journalling.

      You're comparing the time to write 10megs to RAM, read it back from ram and then remove it from ram against having to write 20000 files worth of metadata (10000 for the creates, another 10000 for the deletes) to disk, plus all the RAM writes/reads..

  6. Need a better test by uslinux.net · · Score: 2, Interesting


    Forgive me if any of this is mentioned inother responses, but...

    First of all, the tests need to be Reiser, XFS, and *Ext3*. Journalling has an impact on performance, even if you're only jounalling the metadata.

    Second of all, you should be testing the latest version of all of these against the latest kernels. 2.4.10 or new.

    Third of all, one test doesn't show any real benchmarks. You need to test reads and writes of small and large files in differing directory structures. Also, testing should focus on the specific performance gains of each, as well as some real world tests. I believe Reiser does dynamic block allocation while ext generally relies on 4kb blocks (I can already see a number of tests on things like sparse files). Partially fragmented filesystem simulation would be beneficial, too (think "news server"). Yes, I know all the filesystems don't easily fragment, but if you fill a filesystem, then start removing some files and adding others, (especially removing small files and adding large ones), you _will_ get a chance to test it.

    Finally, you should consider other filesystems. I think a very good comparison would be ext3, JFS, XFS, and Reiser vs. ext2. That would give you a valid baseline comparison. In addition, testing something like VFAT support under Linux might be interesting :-)

    I think this is a valiant effort, but there's a lot more which needs to be put into it to show any useful results.

  7. This is screwey by OmegaDan · · Score: 2
    If you wanna see reiser shine : put 20,000 files in a single directory and see how long it takes to ls them? The difference between ext2 and reiser will be *seconds* in reisers favor.

    And of course the journaling filesystems are slower, BECAUSE THEY ARE BUSY JOURNALING. Journaling is done for saftey not speed.

    --
    Free Techno/Jazz/DNB/MI Music by guys obsessed with monkeys!
  8. OSD Lab comparison of file systems by Bryce · · Score: 2

    Here's an analysis report on some of the various file systems, graphing the results for easier digestion. :-)

    http://www.osdl.org/reports/journal_fs/