Re: [Qemu-devel] Cluster_size parameter issue on qcow2 image format

[PANKAJ RAWAT]

Thanks for the reply

On Thu, Feb 23, 2012 at 3:46 PM, Stefan Hajnoczi <address@hidden> wrote:

On Thu, Feb 23, 2012 at 10:02 AM, PANKAJ RAWAT <address@hidden> wrote:
> Is the degrade in performance is only due to allocation of large cluster
> during expansion of qcow2 image ?
>
> But the trend is same in case of
> Sequential write
> Random write  of 1 GB data
>
> In random i can understand the sparseness of data
> But in sequential write I don't understand as the write is performed on
> sequential bases
>
> is there is any reason behind it or i am not getting it right ?

Sequential writes still require qcow2 to allocate clusters.

The first write request that touches a new cluster causes qcow2 to
allocate the full 1 MB.  Then the next few sequential write requests
overwrite in-place (these requests do not suffer allocation overhead).

Now if you imagine doing 4 KB requests in the guest with 1 MB cluster
size, you should find that the host is doing n * 4 KB / 1 MB - n * 4
KB extra I/O to the image file because it is zeroing each allocated
cluster!

Linux I/O requests tend to be 128 or 256 KB maximum with virtio-blk.
So even if your request size in guest userspace is 1 MB you're
probably doing multiple virtio-blk requests underneath.  Therefore you
are hitting the sequential allocating write pattern I described above.

The exact overhead depends on your application's I/O request pattern
but it's unsuprising that you experience a performance impact.

Stefan

--

Pankaj Rawat