Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Performance of Ext2, ReiserFS, and XFS? 38

Posted by Cliff 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."
This discussion has been archived. No new comments can be posted.

Performance of Ext2, ReiserFS, and XFS? More

Performance of Ext2, ReiserFS, and XFS?

Comments Filter:

  • A test is not a test is a test.... (Score:3, Insightful)

    by pwagland ( 472537 ) on Wednesday October 24, 2001 @08:23AM (#2471499) Journal
    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!
  • How important is deletion speed for you? Deleting files on an XFS filesystem is notoriously slow. That does not make XFS a slow filesystem. If you've got really deep and large directory trees, XFS will be able to handle that much better than EXT2FS.

    Raw transfer speed will probably be better on a EXT2FS filesystem. Depending on the FAT16 implementation, writing to a FAT16 filesystem is going to be even faster. This has been tested using PostgreSQL and a large database (check the pgsql mailinglists for details).

  • Why the world spins... (Score:3, Interesting)

    by autocracy ( 192714 ) <slashdot2007@sto ... .com minus berry> on Wednesday October 24, 2001 @08:56AM (#2471611) Homepage
    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...)

    • 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
      • ... 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.
        • How is this even remotely a reply to what I said?

          I was trying to clarify what I think was a factual error in Autocracy's observations of the write/read/delete data. Specifically, I think he interpreted the ext2 read as .something instead of .oh-something.

          How does "yeah, but dirty restarts are faster" relate? I don't think that they do. I think that you are looking for a "my fs rulz, your fs sux" pissing contest, and you have mistaken me for some sort of ext2 zealot. So you've thrown out this non-sequiter to try to get a nice flame war going.

          The problem is that you are doomed to look like a fool in any flame war, because you can't even follow the conversation.

          Sorry, pal.

          -Peter
      • 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).

    • Time to come up after a crash (either power failure or software) is only relevant if that happens to the filesystem very much. Certainly our filesystems on our file servers won't experience that more than once in a blue moon (we have UPSes and run stable kernels); I suspect more than a few people are in that sort of environment. If crashes and powerfails are at all common, you have larger problems than filesystem performance.

      One can certainly argue that in most environments the performance drop (if any) is worth paying for the crash recovery (neglecting that several journalling filesystems have some uncomfortable crash recovery issues because they only journal metadata). But that is a very different argument from a claim that fast crash recovery makes performance differences irrelevant.

  • 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.
    • The 2gig limit of which you speak is not a result of your 32 bit cpu. It's your kernel, and support libraries. I use ReiserFS and ext2 and both readily support much larger files.

    • 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!".
      True, but it also depends very much on the value of the -notails mount flag. Try comparing the amount of disk space used by the various filesystems (and reiserfs with and without -notails) to see what I mean. Reiserfs small file claim is that it can store them particularily well.
  • Out of curiosity, when was this test done? I ask because it seems odd to have used kernel 2.4.2 (which came out, what, in February?) and also to not have benchmarked ext3. Especially as this is the filesystem which has had almost no performance tests done (or at least, linked form /.) so far, unlike the others.

    It's a shame that there isn't a url to see more/find the methodology used, etc.
    • I have no benchmarks, but I can say that since I updated to EXT3, that it has felt a bit slower during disk I/O. I'd love to see some benchmarks to prove this, but don't have the means to test this for now.
  • Your benchmark is not up2date thus valid, becouse:

    - you used old kernel
    - you used old XFS release, 1.0 and not 1.0.1 which is official

  • 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.
  • Lets be honest here, now that Linux has high perfomance filesystems a lot of tuning will play a big role in how well your fs performs.

    As for this test, doesn't seem quite right, 10,000 1k files written and read concecutively? Uh doesn't sound like a regular day for my computer.

    And what are the default configs for each of these FS's? Sounds like they may be differnt? Also need data on CPU, memory and cache usage, don't we?

  • Something fishy (Score:5, Insightful)

    by hardave ( 87702 ) on Wednesday October 24, 2001 @12:06PM (#2472576)
    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.

    • Re:Something fishy (Score:3, Informative)

      by kijiki ( 16916 )
      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..

  • Need a better test (Score:2, Interesting)

    by uslinux.net ( 152591 )

    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.
    • If you're curious, check out these previous articles from Slashdot. They report of a Spanish user group [bulmalug.net], who benchmarked JFS, XFS, Reiser, ext2 and Fat32. The only one missing was ext3, and I for one would like to see them revisit these tests, as they seemed to do it well:

      The first attempt [slashdot.org]
      The second [slashdot.org]

      (PS, your post should really have been modded as redundant, but who cares as Slashdot is owned by VA Linux - the home of redundancies)
      • (PS, your post should really have been modded as redundant, but who cares as Slashdot is owned by VA Linux - the home of redundancies)

        Yes, well, I, like many, keep my moderation very high, as to block most of the noise, so occasionally I miss a good point which hasn't been fully modded up.

        Kinda the reason I mentioned "pardon me if this has been noted before, but..."

  • Ext3? (Score:1)

    by addaon ( 41825 )
    Given that ext2 seems to be the clear winner now (which I'm not quite sure I believe, but it is a more mature solution on Linux), how does ext3 perform? I was somewhat surprised to see it left out of these tests... is it possible it inherits some performance from ext2?
  • 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.

  • 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/ [osdl.org]

  • My reply is a bit late...

    The test creates, reads, and deletes 25000, 1024 byte files. All files are created in a single directory. You can get the test script and see further results at http://ridicule.net/~ixx/test_fs.html

    There are two 1gig partions (Maxtor 6GB UDMA 33), formatted for ext2 and reiserfs. I run the test on each partion 3 times then reformat, switching partions (reiserfs on first ext2 on second). I used 4096 as the block size for both file systems.

    A summary of the results is:

    Ext2
    Write: 77 seconds
    Read: 63 seconds
    Delete: 6 seconds

    Reiserfs
    Write: 9 seconds
    Read: 29 seconds
    Delete 3 seconds

    Disk usage first line is before creation, second line is after creation.

    File system usage (given by df) for ext2:

    Filesystem 1k-blocks Used Available Use%
    /dev/hdd1 1007960 20 956736 1%
    /dev/hdd1 1007960 100512 856244 11%

    File system usage (given by df) for reiserfs:

    Filesystem 1k-blocks Used Available Use%
    /dev/hdd2 1024092 32840 991252 4%
    /dev/hdd2 1024092 60920 963172 6%

Slashdot Top Deals

Neutrinos have bad breadth.

Close