Slashdot Mirror
Performance of Ext2, ReiserFS, and XFS?
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:
- Ext2 (0.45, 0.093, 0.13)
- ReiserFS (2.5, 0.45, 0.94)
- 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."
Because Earl's friend from the old Nexabit gang says "WHOOT!"
Windows? http://www.microsoft.com, duh!
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!
Try 2.4.13. You'll notest vastly different performance on all accounts.
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).
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
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.
Firstly, you tested using only small files. XFS can deliver streaming video and large files better than the other FS'es. Secondly, EXT2 is not a journaled filesystem, but EXT3 is.
I think that you should really compare EXT3 to XFS and ReiserFS to compare apples to apples.
Thanks for taking the trouble to do this comparison though, its valuable info anyway.
bwanagary
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.
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?
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.
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.
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?
I've had this sig for three days.
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!
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/
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%