Red Hat Bugzilla – Bug 755670
KVM doesn't like qcow2 images with cluster size of 512
Last modified: 2013-01-09 19:33:03 EST
Description of problem: KVM Virtual machines have problems with qcow2 images with cluster sizes of 512. Disk access time is terrible. Version-Release number of selected component (if applicable): kernel-3.1.1-1.fc16.x86_64 qemu-img-0.15.1-2.fc16.x86_64 qemu-kvm-0.15.1-2.fc16.x86_64 qemu-system-x86-0.15.1-2.fc16.x86_64 qemu-common-0.15.1-2.fc16.x86_64 libvirt-0.9.6-2.fc16.x86_64 virt-manager-0.9.0-7.fc16.noarch How reproducible: Create a virtual disk image: $sudo qemu-img create -f qcow2 -o cluster_size=512 node1.img 6G Create a standard virtual machine using virt-manager Ensure that the virtual drive is using virtio Do an install from Fedora 16 x86_64 ISO file. It is takes hours.
When creating the VM from the wizard, OS type was Linux, Version was "Fedora 16"
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Come on guys, there is clearly a bug here.
Where this install is spending most of the time? Does it ends much faster w/ a larger cluster size like 1M ?
Joshua, this is most likely not a bug, but expected behaviour. Using 512 byte sectors means that you have 128 times as much metadata writes as with the default cluster size. This does hurt performance a lot. What are the reasons for using such a small cluster size? I haven't seen it used anywhere outside testing or debugging until now. Benchmarks have shown that the default cluster size of 64k is optimal performance-wise for most workloads. One thing that you should make sure when using small cluster sizes is that you use a cache mode that allows metadata updates to be batched, i.e. one of cache=none/writeback/unsafe. Do you already use one of these? Another option may be metadata preallocation, though I'm not sure if it achieves what you intended.
I didn't intend anything, it was simply curiosity. It took hours... most the time was spent in the package installation