Re: [Qemu-discuss] qcow2 performance improve

[Alberto Garcia]

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
clusters.

More information here:

   https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg01229.html

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

   http://lists.nongnu.org/archive/html/qemu-block/2018-05/msg00180.html

More information about those patches here:

   http://lists.nongnu.org/archive/html/qemu-devel/2017-11/msg00059.html

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:

   https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg01033.html

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

   https://www.youtube.com/watch?v=kmUxIOTiGNo

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

   https://www.youtube.com/watch?v=svMpxzl9yI4

I hope that helps,

Berto