Performance of Ext2, ReiserFS, and XFS? 38
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."
A test is not a test is a test.... (Score:3, Insightful)
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!
Filesystem performance (Score:1)
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)
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...)
Re:Why the world spins... (Score:2)
So, to answer your question directly, yes, I see a trend, ext2 is fastest in all three areas.
-Peter
Re:Why the world spins... (Score:2)
Re:Why the world spins... (Score:1)
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
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
Re:Why the world spins... (Score:1)
So what I was saying was that the benchmarks are irrelevent, really. Nice to see that went unnoticed.
Cheerio.
Re:Why the world spins... (Score:2)
Re:Why the world spins... (Score:1)
Re:Why the world spins... (Score:1)
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.
Scalability (Score:2)
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.
Re:Scalability (Score:1)
Re:Scalability (Score:1)
When was this test done? (Score:1)
It's a shame that there isn't a url to see more/find the methodology used, etc.
Re:When was this test done? (Score:1)
XFS 1.0.1 (Score:1)
- you used old kernel
- you used old XFS release, 1.0 and not 1.0.1 which is official
FS tests (Score:2)
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.
File system tuning...... (Score:1)
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)
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)
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)
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.
Re:Need a better test (Score:1)
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)
Re:Need a better test (Score:1)
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)
This is screwey (Score:2)
And of course the journaling filesystems are slower, BECAUSE THEY ARE BUSY JOURNALING. Journaling is done for saftey not speed.
OSD Lab comparison of file systems (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/ [osdl.org]
Ext2 and reiserfs create, read, delete test. (Score:1)
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%