BTRFS EXT3 EXT4 XFS and KVM virtual machine: a host-side filesystem comparison

Written by Gionatan Danti on . Posted in Linux & Unix

User Rating:  / 14

BTRFS and preallocated QCOW2 images

But – wait: if bad BTRFS performances is a direct results of its enormous fragmentation, preallocating the entire virtual HD image we should be able to greatly reduce this phenomenon.

So, I did a Windows 7 x64 install test with a manually preallocated VM disk image (by using the “qemu-img -f qcow2 -o preallocation=metadata Win7.img 32000000000” command). Using this command, I obtain a clean VM disk image with only 3 fragments. This lea to a great speed boost:

BTRFS with KVM: preallocated vs non-preallocated QCOW2 images

As you can see, the preallocated image grant a very big speed increase: while BTRFS remain slightly slower then EXT3/4 and XFS, it is way better then before.

Unfortunately IOMeter tests show that, after a promising start, performance had a sharp drop: this is to be expected, as the current Fedora qemu-img tool can only do a metadata preallocation vs full preallocation (supported on RHEL 6.2). This, coupled with the “sparse file” support typical of advanced filesystems, means that, when the file is filled with real data, fragmentation become again a problem. For reference, the attained fragmentation level after IOMeter test was at 122819 fragments.

While I could simulate a full preallocation using some shell trick, I think that this is beyond the scope of this article. The lesson is clear: BTRFS is not only too young and unproven, but way too much fragmentation prone to be used as a virtualization back-end filesystem.


#1 NGRhodes 2012-07-25 12:07

When looking at fragmentation, do not forget that EXT4 supports a maximum 32K blocks in an extent, which at the default 4KB block size is 128MB.
As your benchmarks show, does not appear to be a performance limitation.
What would be more interesting is rerunning the benchmarks on an aged filesystem and compare how performance degrades with age.
#2 Gionatan Danti 2012-07-30 11:20
Hi NGRhodes,
sorry for the late reply.

You are correct about EXT4 extent size, but theoretically nothing prevents 2 extents to be placed one after the other. In fact, the filefrag utility checks if two extents are consecutively placed and, in this case, it does not report two different fragments, but only one.

Do you have any proposal about the aged filesystem? Any idea is welcomed ;)
#3 Jack Douglas 2012-10-14 21:15

Thanks for the very helpful article. Would you be open to the suggestion of running the same tests with OCFS2 on a single node (it is the only fs other than btrfs with 'reflink' file snapshots that are very useful for backing up VMs)

Kind regards
#4 Boki 2016-04-21 12:59
Thanks for great article, and now, almost 4 years later, is there any new diff results or suggestions?

You have no rights to post comments