EXT3 vs EXT4 vs XFS vs BTRFS linux filesystems benchmark

Written by Gionatan Danti on . Posted in Linux & Unix

User Rating:  / 128
PoorBest 

Fragmentation: Sysbench write test

The previous untar test was quite simple from a fragmentation standpoint: the extracted files are quite small and are created sequentially. But how these filesystems behave with a more complex sequential test? Let's see the sysbench sequential write test, that create 128 files, each 16 MB long (for a total of 2 GB):

Sysbench sequential write - fragmentation level

Ehm... it appear that without delayed allocation (remember that the one write/one fsync() paradigm effectively disable it) BTRFS has some really BIG problem with fragmentation. This also explain the low read speed found in previous test. Give a look to the same graph without the BTRFS data point:

Sysbench sequential write - fragmentation level without BTRFS

We can see that EXT3 is again worse than EXT4 and XFS. When used with delayed allocation, these two filesystems can score very near to the perfect one file/one fragment ratio. When we force the one write/one fsync() pattern (effectively disabling delayed allocation) the fragmentation level increase, but it remain less that 2 times the EXT3 one.

For now, we concentrated ourself on sequential write test. In this kind of tests we saw very good results from EXT4 and XFS, at a point were we can ask ourself if it is worth using an (eventually available) on-line or off-line defragmenter. How about random write test which are, by definition, much more fragmentation-prone? This test use the same 128, 16 MB long files, but rewrite on them 10000 16 KB long requests (for a grand total of over 156 MB of random written data):

Sysbench random write - fragmentation level

The random write test show us that, in a heavy environment, all these Linux filesytems can become very fragmented. As expected, in this case the delayed allocator is of no help (it can not merge these random writes to different locations in one fragment). EXT4 seems to have a small lead over XFS and EXT3, while BTRFS is much worse. However, considering that XFS has an usable on-line defragmenter, I think that it has the edge in this test also.

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.

Comments   

 
#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

Thanks.
 
 
#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?


Thanks,
Jakub
 
 
#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