Bug 755670

Summary: KVM doesn't like qcow2 images with cluster size of 512
Product: [Fedora] Fedora Reporter: joshua
Component: qemuAssignee: Kevin Wolf <kwolf>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: amit.shah, berrange, clalancette, dougsland, dwmw2, ehabkost, extras-orphan, itamar, jaswinder, jforbes, knoel, markmc, notting, quintela, scottt.tw, tburke, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-03-23 08:36:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description joshua 2011-11-21 17:53:30 UTC 
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.
Comment 1 joshua 2011-11-21 17:56:22 UTC 
When creating the VM from the wizard, OS type was Linux, Version was "Fedora 16"
Comment 2 Fedora Admin XMLRPC Client 2012-03-15 17:56:00 UTC 
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 3 joshua 2012-03-16 00:40:24 UTC 
Come on guys, there is clearly a bug here.
Comment 4 Dor Laor 2012-03-18 09:02:04 UTC 
Where this install is spending most of the time?
Does it ends much faster w/ a larger cluster size like 1M ?
Comment 5 Kevin Wolf 2012-03-19 16:14:42 UTC 
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.
Comment 6 joshua 2012-03-22 21:42:24 UTC 
I didn't intend anything, it was simply curiosity. It took hours... most the time was spent in the package installation