qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] reduce write bandwidth of qcow2 driver while allocating


From: Liu Qing
Subject: Re: [Qemu-devel] reduce write bandwidth of qcow2 driver while allocating new cluster
Date: Tue, 29 Aug 2017 11:05:04 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Aug 28, 2017 at 05:40:48PM -0400, John Snow wrote:
> 
> 
> On 08/28/2017 01:56 AM, Liu Qing wrote:
> > Dear list,
> >     Recently I used fio to test qcow2 driver in the guest os, and found out
> > that when a new cluster is allocated the 4K IO will occupy 64K(default 
> > cluster
> > size) bandwith.
> >     From the code qcow2 driver will fill the unused part of new allocated
> > cluster with 0 in perform_cow. These 0s are set in qcow2_co_readv when the 
> > read
> > destination is not allocated and it has no backing file. Could I forbidden 
> > any
> > further write in copy_sectors if the copy source is not allocated and it has
> > no backing file? So only the requested data is written to the cluster. 
> > Function
> > copy_sectors is only used by perform_cow in the master branch.
> >     Do you think this change is reasonable? Thanks.
> > 
> > 
> 
> CCing qemu-block.
> 
> If I am understanding you correctly, you're noticing an adverse
> performance impact from initial writes to unallocated clusters through
> the qcow2 driver, when qcow2 performs zero-fill of uninitiated clusters.
Yes, that's it.
> 
> First, can you look at sources for current master branch? it hasn't been
> named "copy_sectors" since June 2016, and the function looks a bit
> differently than it did in the version you're looking at, I think.
I checkout the latest master branch and the code path has some changes, but the
zero-fill process still exists. Eric has replied a patch from Anton
which could improve the write performance. Thanks all.
> 
> John
> 




reply via email to

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