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:
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.