[04-NOV-2015: Important update: Since this change in upstream QEMU, which introduces two new options
qemu-img create, this is strongly recommended to use
qemu-img create -f qcow2 preallocation=falloc […] to get the said performance benefits.]
Recently I’ve started using ‘preallocation=metadata’ flag while creating qcow2 disk images to extract some decent I/O performance. Today, while discussing qcow2 disk image performance with Stefan Hajnoczi (thank you!) on irc, I found, using fallocate — which preallocates all the blocks to a file — on a qcow2 disk image would improve disk I/O performance a little more as alls the blocks are allocated to the file ahead of time. (Just to note – fallocate comes w/ the linux standard pkg ‘util-linux-ng’)
Let’s run a quick test to see the disk I/O performance improvement by preallocating all the space in a qcow2 disk.
Create the disk image with ‘preallocation=metadata’
$ qemu-img create -f qcow2 -o preallocation=metadata /export/vmimgs/f16-test1.qcow2 8G Formatting '/export/vmimgs/f16-test1.qcow2', fmt=qcow2 size=8589934592 encryption=off cluster_size=65536 preallocation='metadata'
Let’s check the size of the image in bytes
$ ls -l /export/vmimgs/f16-test1.qcow2 -rw-r--r--. 1 root root 8591507456 Dec 2 16:55 /export/vmimgs/f16-test1.qcow2 # Also, print the allocated file size in blocks $ ls -lash /export/vmimgs/f16-test1.qcow2 1.4M -rw-r--r--. 1 root root 8.1G Dec 2 16:55 /export/vmimgs/f16-test1.qcow2
Run fallocate to preallocate space to the disk image:
$ fallocate -l 8591507456 /export/vmimgs/f16-test1.qcow2
Now, re-run ‘ls’ to print the allocated file size in blocks. (Notice that all the disk size, 8G, is now allocated.)
$ ls -lash /export/vmimgs/f16-test1.qcow2 8.1G -rw-r--r--. 1 root root 8.1G Dec 2 16:55 /export/vmimgs/f16-test1.qcow2 $
Also, let’s run ‘qemu-img info’ to get the disk size, virtual size.
$ qemu-img info f16-test1.qcow2 image: f16-test1.qcow2 file format: qcow2 virtual size: 8.0G (8589934592 bytes) disk size: 8.0G cluster_size: 65536 $
As a simple test, I used the above disk image to create an @core only Fedora-16 guest(on a Fedora-16 host) and clocked the timing — it took roughly 5 min 32 sec to finish. While, previously, w/o fallocateing a disk image, when I clocked the same f-16 timing, it took nearly 8 minutes. So, there is a decent improvement noticed here.
With this, Stefan noted, disk write speed inside the guest machine should also be improved, when blocks are written for the first time. And also, due to less disk fragmentation — as all the space was preallocated in one operation — there would be fewer disk seeks during large read operations.