Bug 755670 - KVM doesn't like qcow2 images with cluster size of 512
Summary: KVM doesn't like qcow2 images with cluster size of 512
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu
Version: 16
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kevin Wolf
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-21 17:53 UTC by joshua
Modified: 2013-01-10 00:33 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-03-23 08:36:23 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.