EXT3 vs EXT4 vs XFS vs BTRFS linux filesystems benchmark

Written by Gionatan Danti on . Posted in Linux & Unix

User Rating:  / 131

Fragmentation: Linux kernel untar

We speak about fragmentation when a single file is split into multiple, noncontiguous parts called fragments. As with standard mechanical drive each head seek is very expensive (5-15 ms on most product, while the CPU clock period of a entry-level process is measured in ns, some 6 orders of magnitude lower) fragmentation is #1 enemy for any filesystem. An heavily, random fragmented filesystem will be much slower than a low fragmented one.

This problem can be addressed by using at least one of these two strategies:

  • running, on a regular base, a defragmenter (a software specifically written to reorganize file on disk, so that the various file fragments are reorganized in greater, single contiguous fragment);

  • implementing some non-fragmenting logic directly within the filesystem (so that for each write the filesystem try to use contiguous disk space).

The first solution is surely quite uncomfortable (as we must deal with periodic defragmentation), but it can implement some complex logic to almost totally eliminate fragmentation. The second possibility is much more transparent (we haven't to do anything special), but can be more fragmentation-prone.

Windows system choose the first approach: starting from Win2000, Microsoft include an on-line defragmenter for NTFS volumes.

Linux filesystem historically choose the second path: all the benchmarked filesystems integrate some non-fragmenting logic and not all filesystems have an on-line or even off-line defragmenter. XFS is the only one to have a stable, online defragmenter at the moment (EXT4 has a beta online defragmenter called e4freefrag but it is not included in any distribution at this time).

So, how these filesystems behave regarding fragmentation? Let's start with a simple, common task: untar the Linux kernel. This operation sequentially creates over 32000 files:

Linux kernel untar - fragmentation level

As you can see, in this simple operation the recent filesystems are perfect, with an average of one fragment per file. The aging EXT3 filesystem (the only one without delayed allocation capability) is quite worse but, after all, it is not so bad.

UPDATE: preparing the system for another benchmark, I noticed that, in contrast to what written in Fedora 14 documentation, write barriers were non enabled on EXT3 filesystem. Please read the updated "Conclusions" page.


#1 Max 2012-08-26 15:49
Thank you for this very interesting article. I'll go with ext3, mostly because of your verdict for it being a good and balanced filesystem.
#2 Gionatan Danti 2012-08-26 16:11
Hi Max,
I'm happy that you found my article interesting.

However please note that, as you can read in the updates, EXT3 was incorrectly benchmarked with write barrier off, while all other filesystems used barrier on.

This means that EXT3 data were somewhat flawed. For up-to-date data, please read my latest article here: http://www.ilsistemista.net/index.php/linux-a-unix/33-btrfs-vs-ext3-vs-ext4-vs-xfs-performance-on-fedora-17.html

#3 Kuba 2012-10-09 15:01
Hi Gionatan,

Could you please let me know what sysbench parameter you have used to perform these tests?

#4 http:// 2014-03-08 09:57
I believe what you published was very reasonable. But,
what about this? suppose you typed a catchier post
title? I mean, I don't want to tell you how to run your website, however suppose you added something to possibly get people's attention?
I mean EXT3 vs EXT4 vs XFS vs BTRFS linux filesystems benchmark is a little vanilla.

You ought to glance at Yahoo's home page and see how they write
article headlines to get people to open the links.

You might add a video or a pic or two to get readers excited about everything've got to say.
Just my opinion, it could bring your website a little bit more interesting.

You have no rights to post comments