BTRFS vs EXT3 vs EXT4 vs XFS performance on Fedora 17

Written by Gionatan Danti on . Posted in Linux & Unix

User Rating:  / 19
PoorBest 

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 products, 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 regular basis, a defragmenter (a software specifically written to reorganize files on disk, so that the various file fragments are reorganized in greater, single contiguous fragments); 
  • 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 defragmentations), 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 historically choose the first approach: starting from Win2000, Microsoft include an on-line defragmenter for NTFS volumes. Linux filesystems historically choose the second path: all the benchmarked filesystems integrate some non-fragmenting logic and, until recently, not all filesystems had an on-line or even off-line defragmenter.

While two years ago only xfs had a stable, widely distributed online defragmenter, now the situation is way better, as both ext4 and btrfs have stable defraggers that are included in most (if not all) distributions.

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

BTRFS EXT3 EXT4 XFS: Untar fragmentation

All examined filesystems shows great resilience against framentation: ext3 is the worse here, but it manage to keep fragmentation at about 1.03 fragments per file. The other filesystems, being capable of more sophisticated allocation policies (eg: extents, delayed allocation, etc.), show even better results, ending with the perfect situation were one file = one fragment.

Comments   

 
#1 Roger 2012-06-20 00:40
Could you share with us the mount options used to mount the file systems for these benchmarks?
 
 
#2 Gionatan Danti 2012-06-20 08:00
Hi Roger,
apart the write barriers option (which was manually enabled on all filesystems, ext3 included) I left the default mount options at their default settings.

To tell the truth, Fedora enable barriers by default on ext3 also; however, this is a Fedora-specific change that not all distributions followed (apart SuSe, I think).

The rationale behind this decision to not mess with mount options is that, as default settings are the most used settings, they _must_ be adequate; the failure to set them to reasonable default will affect many users.

On the other hand, write barriers should really be enabled to do an apple-to-apple comparison, so it is the only option I wish to manually enable.

Regards.
 
 
#3 Oliver 2012-07-15 14:57
From official fedora documentation, Fedora 17 features the 3.3.4 Linux kernel [1].

However, I read on the first page of this article [2] the use of Fedora 17 3.4.x kernel branch.

I may be wrong (I do not use Fedora) but please explain where have you find this Linux kernel version within Fedora 17.

PS: I like article of this high quality, thanks ;)

[1] http://docs.fedoraproject.org/en-US/Fedora/17/html/Release_Notes/sect-Release_Notes-Changes_for_Sysadmin.html#id579836
[1] http://en.wikipedia.org/wiki/Fedora_%28operating_system%29#cite_ref-47

[2] http://www.ilsistemista.net/index.php/linux-a-unix/33-btrfs-vs-ext3-vs-ext4-vs-xfs-performance-on-fedora-17.html
 
 
#4 Gionatan Danti 2012-07-15 16:39
Hi Oliver,
you are right: F17 base image ships with kernel version 3.3.x.

However, a yum update resulted in kernel 3.4.x being installed, so I tested with this updated kernel release.

See here also: https://bugzilla.redhat.com/show_bug.cgi?id=754481

Regards.
 
 
#5 Oliver 2012-07-15 22:44
Thanks

OK I see "F16 and F17 will be rebased around the time 3.4.1 is released" on the bottom of the page.
 

You have no rights to post comments