On Thu, Feb 23, 2012 at 10:02 AM, PANKAJ RAWAT <pankajr...@gmail.com> 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
