Skip to content
January 11, 2012 / gus3

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!

System configuration

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.

Filesystem options

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.”

Filesystem results

[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.

Higher is better.


A 5-thread dbench load is largely unchanged from a year ago.

Higher is better.


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

Elevator results

Higher is better.


Higher is better.


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


Leave a Comment
  1. Anon / Jan 13 2012 5:24 pm

    label your y axis….

    • gus3 / Jan 13 2012 6:06 pm

      You make a fair request, but I don’t want the results from my machine to become some kind of benchmark for other systems. 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. I provide an archive with the scripts, and the results, via the link at the end of the article.

  2. nekraH / May 19 2012 8:43 am

    Sorry, but I don’t agree. In my opinion, the point isn’t as much that of avoiding the risk that your data become – sooner or later – sort of a benchmark-fetish: as it is, instead, that of how reliably / how clearly can the information you provide be processed and used from, say, a “generic / average” reader who has possibly happened to “stumble” into this page. And, while in general the information you provide is useful, I’d nonetheless say that, in the “ease of processing / interpretation” department, you don’t really maintain what you promise.

    Take, for example, your first graph: ‘fastest relative throughput / kernel 3.2 / 5 threads’. Were the y-axis scale-values negative, and ordered from 0 (bottom) to -infinity (top) (which, strange as it may seem, would nonetheless be an absolutely reasonable option, GIVEN THE TITLE OF THE GRAPH), ext2 would presumably be the worse of the bunch; while, on the contrary, it would result (again, presumably) to be the better, were the y-axis scale ordered from 0 (bottom) to +infinity (top): i.e., the “standard / default” option. In other words: is the interpretation one has to give to the graph, “the higher is the bar – the fastest is the filesystem’s throughput”, or is it the other way around? An explicit mention, at least of the UNIT in which the y-axis scale is expressed, would avoid any misunderstanding.

    More or less, the same applies also to the other graphs. Which is the very reason why, after all, one usually labels both axes in a XY-graph: to avoid any misinterpretation of the given information. Else, it makes no sense to provide some information in graphical form, and then force its possible users to read some text in order to decipher the graphs ;)

    • gus3 / May 19 2012 4:13 pm

      I wish I could shake your hand. Yours is one of the most well-thought-out disagreements I’ve ever gotten here. I think the point stands about “0 to some particular maximum,” but you’re right that I could have labeled the Y axis origin, and indicated “higher is better” in the title. I think someone looking for performance would understand this, but as a matter of standard charting I should indicate at least that much. I shall certainly do so in the future.

      Thanks for reading and responding!

  3. ryanch94 / Jun 9 2012 12:01 pm

    How about for Windows file systems? I use NTFS for my Windows 7 but I’ve read that FAT32 is faster…is it?

    • gus3 / Jun 9 2012 6:49 pm

      NTFS is descended from the Files-11 filesystem used on VMS, so it has a full privilege system, versioning (multiple streams), as well as logging (filesystem journal) as of NTFS v3. It also has a better allocation scheme, and can handle sparse files with as much ease as any Unix/Linux filesystem. Naturally, managing these things increases the CPU load. So, what you lose in speed, you gain in capability.

      (But please bear in mind, I have never used NTFS on any regular basis. I haven’t used any Microsoft operating system regularly for 14 years.)


  1. Links 13/1/2012: CrossOver 11, Mageia 2 Alpha 3 | Techrights
  2. رادیو ۲۴: چهارشنبه، ۲۸ دی ۱۳۹۰ | رایان پي سي
  3. رادیو ۲۴: چهارشنبه، ۲۸ دی ۱۳۹۰ | GilAsus
  4. Finding the Fastest Filesystem, 2011 Edition « I Am, Therefore I Think

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: