EXT3 vs EXT4 vs XFS vs BTRFS filesystem comparison on Fedora 18

Written by Gionatan Danti on . Posted in Linux & Unix

User Rating:  / 44
PoorBest 
Page 4 of 10

Sysbench file tests

Benchmark profile:
- sequential test: 1 thread / 16 files 64 MB each / 2 MB block size
- random test: 1 thread / 16 files 64 MB each / 4 KB block size

Its now the turn of another synthetic benchmark: sysbench. It enable us to measure filesystem performance with sequential and random patterns and with normal (cached) or direct (not-cached) operations.

In sequential tests all filesytems behave more or less the same: this is expected, as these values depend primarily on the disk hardware subsystem. However, we can see that with synchronized writes (using fsync) BTRFS is somewhat slower then EXT3/4 and XFS.

Random I/O sysbench results always puzzled me a bit: it is clearly impossible to obtain over 13 MB/s with a mechanical disk and a truly randomic pattern. Anyway, we must score a point for XFS and BTRFS random read performance. Even their (much more realistic) random write speed is higher then EXT3 and EXT4.

Let see something about direct I/O performances. Sequential first...

… and then random:

If in the sequential direct I/O benchmark we don't see many differences relative to normal, cached I/O, in the random direct I/O test we see some variance. In detail, BTRFS is the fastest when reading, while XFS is the write champion.

Latest articles:

Comments   

 
#1 Jan 2013-06-27 15:42
Thanks for the test. It seems, as if btrfs is a bit Janus-faced: sometimes very fast, sometimes very slow.

It would be very interesting for future tests, how ZFS on Linux performs. Especially, after it has become "productive" some weeks ago.
 
 
#2 Gionatan Danti 2013-06-27 16:12
Hi Jan,
this is surely a good idea ;)

I will investigate this possibility for the next review.

Regards.
 
 
#3 Altr 2013-12-21 10:49
Thank you for the benchmarks!
 
 
#4 Iván Baldo 2014-04-14 03:12
For databases or virtual machine images, you should disable the copy-on-write semantics of BTRFS.
You don't need to set the entire filesystem to be non COW, only the directory and files that need it (chattr -C flag).
 
 
#5 Gionatan Danti 2014-04-14 09:39
Quoting Iván Baldo:
For databases or virtual machine images, you should disable the copy-on-write semantics of BTRFS.
You don't need to set the entire filesystem to be non COW, only the directory and files that need it (chattr -C flag).


Hi Ivan,
you are right. Anyway, I benchmarked BTRFS even with disabled CoW and found that, for virtual machines at least, it performs noticeably worse than a traditional filesystem as EXT4.

You can read more here:
http://www.ilsistemista.net/index.php/linux-a-unix/36-btrfs-mount-options-and-virtual-machines-an-in-depth-look.html

The only catch is that both tests are somewhat old now, being performed on Fedora 17 and 18. I should really see if with newer kernels BTRFS performances are better now.

But I have so little time ;)
 
 
#6 Dan 2015-10-09 06:37
It's two years later, but this post still comes up tops on a search and the conclusions is outdated. Critical data requires historical snapshots AND backups (preferably backups of the historical snapshots). Big critical data requires applications that are well written to do atomic transactions leaving the disk always consistent (assuming the fs supports it) and then requires atomic backups leaving the backups consistent. This simply is NOT achievable (ie impossible) with ext3 or ext4. Adding some small extra stability risks to the many risks that already exist is a small price to pay for proper protection from those risks. NTFS has had shadowcopies for ages by the way. Actually building a backup scheme to leverage these tools in a smart way isn't so simple, but it's worth doing.
 

You have no rights to post comments