EXT4 vs XFS: large volumes with high-end RAID controller

Written by Gionatan Danti on . Posted in Linux & Unix

User Rating:  / 7
PoorBest 

Bonnie++ results

Sequential and random read/write speeds are two factors that can greatly influence final applications speed. Let's start examining Bonnie++ sequential speed and CPU usage:

EXT4 vs XFS

While EXT4 and XFS generally show comparable results both in normal, cached mode and in synchronous mode, XFS lead the sequential output (write) test by a large margin.

What about random speed? Bonnie++'s random I/O speed return the number of seeks per second that the disk subsystem can sustain:

EXT4 vs XFS

The mechanical nature of current hard disks implies results that, in spite of the fast RAID controller, are some order of magnitude lower than the sequential ones: considering 512 byte long sectors, we are speaking about a maximum I/O transfer rate of ~507 KB/s. Considering 4096 byte long sector, the I/O transfer rate grows to a maximum of ~4059 KB/s. In this test, we see that EXT4 has a slight advantage.

Let's now see file creation/deletion, aka metadata handling, performance. First, normal mode:

 EXT4 vs XFS

The faster controller really help XFS (relative to H200 controller's results) but EXT4 remain the strong winner, scoring some very high results. In file deletion, EXT4 is so fast that the test takes too little time to produce a valid score.

Now, synchronous mode:

EXT4 vs XFS

This time, XFS was the best.

An important thing to note is that Bonnie++ sometime crashed the entire machine when running on top of EXT4 filesystem. While the problem remain under investigation, it seems that it happens when the machine has a large amount of (in-memory) cached disk block and an heavy, synchronized workload is executed. While Bonnie++ was the only test that trigger the crash, the fact that it bring down the entire machine is a bad thing. XFS, on the other hand, never had this problem.

Comments   

 
#1 Evgeny 2012-12-10 07:21
it's looks that you fsck time ext4 isn't true.
I think that you ran fsck.ext4 /dev/sd__something__
without "-f" key. It's means that fsck FS state
tune2fs -l
...
Filesystem state: clean
...
and if it clean do nothing
 

You have no rights to post comments