Linux File System Benchmarks
Preface
There are lies, damn lies and benchmarks... Only a fool would base his/her decision on benchmark results from a single source.
I recommend you download the following script and run your own benchmarks, in your own enviroment just to be sure.
Because no
single file system is the best in all situations, determining which
file system is the best for your application is not always easy.
However, as you will see for yourself, picking the right file system
can offer performance gains in excess of 95%.
As a starting point, here are a few questions to ask yourself:
1. Do you want a journaling file system or not? (ie: Can you afford long FSCK times?)
2. Is your application CPU limited, or I/O limited?
If your application is CPU limited, obviously you want to choose a file system that uses the least amount of CPU as possible. On the other hand, if your application is I/O limited, you want to choose a file system that runs all the tests in the shortest amount of time, regardless of the CPU usage. If your not sure, or want the "best bang for your buck", your decision is not so clear cut. Also keep in mind that some file systems have obvious strengths or weaknesses, offering much better performance in very specific applications. (ie: When working with many small files, or many large files.)
As a starting point, here are a few questions to ask yourself:
1. Do you want a journaling file system or not? (ie: Can you afford long FSCK times?)
2. Is your application CPU limited, or I/O limited?
If your application is CPU limited, obviously you want to choose a file system that uses the least amount of CPU as possible. On the other hand, if your application is I/O limited, you want to choose a file system that runs all the tests in the shortest amount of time, regardless of the CPU usage. If your not sure, or want the "best bang for your buck", your decision is not so clear cut. Also keep in mind that some file systems have obvious strengths or weaknesses, offering much better performance in very specific applications. (ie: When working with many small files, or many large files.)
Summary
All benchmarks were run with the v2.6 kernel series. Please do not assume you will see similar results with v2.4 series kernels!
Best bang for your buck - JFS or
XFS:
For I/O limited applications - ReiserFS v4, XFS, or ReiserFS v3:
While not
the fastest file systems, both of them consistently perform close to
EXT2, while using minimal CPU. XFS seems to be faster over a wider
range of benchmarks, however it does use slightly more CPU than JFS.
While JFS really starts to slow down with lots of files.
For I/O limited applications - ReiserFS v4, XFS, or ReiserFS v3:
This
category isn't as clear cut as the others, it really depends on how
many files, and what the size of the files are.
ReiserFS v4 is by far the fastest file system benchmarked here, but keep in mind it is still *EXPERIMENTAL*. However its performance in the Bonnie++ benchmark deserves recognition, up to 95% faster than EXT3, and 65% faster than ReiserFS v3 is mighty impressive. Though the IOZone benchmarks are not so convincing, there still seem to be some issues to work out. ReiserFS v4 will definiately be worth while keeping an eye on, especially considering some of the exciting new features it offers. Hopefully it gets included in Linus's v2.6 kernel tree.
If your application primarily uses lots of smaller files, ReiserFS v3 is the way to go. If your application uses more medium to larger files, and not a whole lot of them, XFS would most likely be a wise choice.
For CPU limited
applications - JFS:ReiserFS v4 is by far the fastest file system benchmarked here, but keep in mind it is still *EXPERIMENTAL*. However its performance in the Bonnie++ benchmark deserves recognition, up to 95% faster than EXT3, and 65% faster than ReiserFS v3 is mighty impressive. Though the IOZone benchmarks are not so convincing, there still seem to be some issues to work out. ReiserFS v4 will definiately be worth while keeping an eye on, especially considering some of the exciting new features it offers. Hopefully it gets included in Linus's v2.6 kernel tree.
If your application primarily uses lots of smaller files, ReiserFS v3 is the way to go. If your application uses more medium to larger files, and not a whole lot of them, XFS would most likely be a wise choice.
JFS is the clear winner here. If your
looking for the absolute least CPU usage, JFS takes the cake.
SCSI vs. IDE:
Is money an object? If your answer is
no, buy yourself SCSI drives, and send me a couple while your at it. ;)
If you're like most of us, and money is an object, SCSI has a hard time comparing to IDE. As you can see from the following benchmarks, a 10K RPM SCSI drive, that hdparm reports can read data up to 45% faster than its 7200 RPM IDE counterpart, in reality only gets you on average a 20% performance gain, depending on the file system.
ReiserFS v4 - gains the most at up to 50%
JFS and EXT3 - gain the least, at around 5-20%, shockingly JFS was even slower in one run.
Considering for the same disk sizes (72Gb vs 72Gb), SCSI (including controller) will cost about 5x more than IDE, you could easily build an IDE RAID array that would make up for any reliability short comings IDE may have, and still cost you considerably less. Though I only have personal experience to base this off, and no hard data, SCSI disks are much more reliable than IDE, especially if properly cooled.
If in your opinion a 20% average performance gain is worth paying 5x more for, please refer back to the first line in this section.
If you're like most of us, and money is an object, SCSI has a hard time comparing to IDE. As you can see from the following benchmarks, a 10K RPM SCSI drive, that hdparm reports can read data up to 45% faster than its 7200 RPM IDE counterpart, in reality only gets you on average a 20% performance gain, depending on the file system.
ReiserFS v4 - gains the most at up to 50%
JFS and EXT3 - gain the least, at around 5-20%, shockingly JFS was even slower in one run.
Considering for the same disk sizes (72Gb vs 72Gb), SCSI (including controller) will cost about 5x more than IDE, you could easily build an IDE RAID array that would make up for any reliability short comings IDE may have, and still cost you considerably less. Though I only have personal experience to base this off, and no hard data, SCSI disks are much more reliable than IDE, especially if properly cooled.
If in your opinion a 20% average performance gain is worth paying 5x more for, please refer back to the first line in this section.
|
AMD Opteron 240 - 512Mb
RAM Results
SCSI - 10K RPM 2.6.0-test9 - Bonnie++ | IOZone 2.6.0-test8 - Bonnie++ | IOZone IDE - 7200 RPM 2.6.0-test8 - Bonnie++ | IOZone 2.6.0-test7 - Bonnie++ | IOZone 2.6.0-test5 - Bonnie++ | IOZone Combined All - Bonnie++ | IOZone SCSI vs. IDE Bonnie++ | IOZone Hardware used PII-450 - 512Mb RAM Results Bonnie++ | IOZone Hardware used |
fs_bench.tar.gz
Requires: Python, MySQL, Bonnie++/IOZone
Unrelated Goodies: Add powerful ACL capability to your web application.