[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss]  qcow2 performance improve

From: Jakob Bohm
Subject: Re: [Qemu-discuss]  qcow2 performance improve
Date: Wed, 15 Aug 2018 17:47:57 +0200
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 15/08/2018 17:06, Alberto Garcia wrote:
On Wed, Aug 15, 2018 at 02:22:30PM +0800, address@hidden wrote:
When use cluster_size=1M qcow2 newly created to test "32k rand
write" in the VM,We get low performance within VM。But there
are huge “write” requests in HOST which falls into qemu
stack of"perform_cow".
The reason why this happens is because clusters are the smallest
units of allocation in qcow2. So if you write a new cluster you
have to fill it completely with data. If there was any existing
data (backing file, snapshot), you need to copy it from there.
If cluster_size=1M then every time you send a write request that
needs to allocate a new cluster then you need to write 1MB. It
doesn't matter if the write request is 32KB, 4KB or 512 bytes.
But Our image has not backing file or snapshot.
If there is no backing file or snapshot you still need to fill the
cluster with zeroes, and that's going to be slower with larger

More information here:


There's work to improve that scenario (allocating a new cluster with no
backing file or snapshots), here are some patches:


More information about those patches here:


And that's for the "no backing file" case. The more general solution
would be the subcluster allocation feature that I mentioned in my
previous e-mail:


I gave a presentation last year at the KVM Forum about performance
with the qcow2 format:


Another earlier talk on the same topic by Max Reitz and Kevin Wolf:


I hope that helps,


And don't forget the high-speed solution: Create the qcow2 file with all
clusters preallocated in contiguous file clusters in a non-fragmented file
on the underlying physical disk(s).

I believe there are qemu-img options to create such qcow2 files instead of
a "thin-provisioned" qcow2 file where each virtual cluster written by the
VM will require the qcow2 layer to allocate and map a new cluster from the
underlying file system file, often in a non-ideal physical disk layout.


Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

reply via email to

[Prev in Thread] Current Thread [Next in Thread]