Finding the Fastest Filesystem, 2012 Edition
A new year, and Linux gets a new major kernel version. It’s time for a new filesystem test!
The installed system is once again Slackware64-current, now running on Linux kernel 3.2 at runlevel 1 (no services).
Hardware is the same as before: AMD Athlon 64 X2 4800+, 4G RAM, two SATA interfaces to spread the disk I/O load.
No changes from the previous report. The script is identical, so all filesystem options are the same, including RAID0 on btrfs. Likewise, the development status of btrfs hasn’t changed; it’s still “unstable, not for production use.”
[Edited 2012-01-14: Yes, the charts have no Y-axis labels. As I have explained elsewhere, the point is to show how filesystems, elevators, and CPU speed interact on my system. Once the results are normalized, hard numbers on the Y axes are useless, except in a zero-to-maximum sense. Your system’s actual numbers will almost certainly be different from mine.]
Some filesystems have undergone changes to improve their on-disk integrity or VFS integration, but not without performance penalty.
A 5-thread dbench load is largely unchanged from a year ago.
However, the heavier 20-thread load shows ext2 and ext4 with nearly identical throughput. This is not due to improvements in ext2, but rather changes in ext4 that have improved its reliability, but degraded its performance. Btrfs performance has also dropped from a year ago, but this is to be expected in an ongoing development process. However, it still appears to scale well. (More on this below.)
Completely Fair Queueing (CFQ) continues being unhelpful on my system. Any time CFQ comes out on top for a filesystem, its lead is slim at best. The only exception to this is ext3, with 20 threads and a slow CPU, where it gets roughly 12% over the noop scheduler and 16% over the deadline scheduler. CFQ’s benefit to ReiserFS was only 6% on a slow CPU, but if 6% makes a measurable difference on a production system, it probably isn’t using ReiserFS.
Most filesystems show similar scaling behavior to what they had a year ago. The two biggest differences are btrfs scaling continuously upwards, where it had an early dip last year; and ext2 showing a greater degradation than it did a year ago.
Testing btrfs to 50 dbench processes showed a smooth curve on the plot, so I decided to take the upper limit much higher, to 200 processes. Sure enough, I found the saturation point around 70 processes, after which the degradation became very noisy.
Even if btrfs is still considered “in development,” this is a very impressive feat on a dual-core system. Oracle’s filesystem developers are onto something big; when btrfs passes from “development” to “stable,” I expect it to be a major contender among Linux filesystems.
Conclusion & Suggestion
The Linux kernel 3.2 is in line to become the default for Ubuntu 12.10. With time, other Linux distros will be doing the same. Similarly, btrfs is in line to become the default filesystem in Fedora, even though it is still “in development.” The file I/O layers have changed so much over the past couple years, perhaps it’s time for Linux distribution managers to re-examine what filesystems they use, and how they tune them. Adding the I/O elevator as an option in distros’ GUI tools might be a good idea, since it doesn’t require a reboot to change, and poses no risk to data.
If you wish to run these tests on your own system, or to examine the raw dbench results for my system, the tarball is here (CAPTCHA and 30-second wait required).