Re: [Qemu-discuss] qcow2 performanceimprove
> > > > > 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. > > > > If not fill zeroes and only write guest data ,what`s wrong could > > > > happen ? > > > The following could happen: > > > 1) Guest reads at offset [0, 4k] -> there's only zeroes > > > 2) Guest writes at offset [8k, 16k] > > > 3) Guest reads at offset [0, 4k] -> there's something else now > > Why could guest read the area at offset [0, 4k] has not be writen > > yet ? > Jakob already gave you some answers, but here's a simple one: because > it might have already been written. > If the guest wrote zeroes to [0, 1M] you can't generally assume that > there's an allocated 1MB cluster on the qcow2 file filled with zeroes. > - QEMU can detect that the guest tried to write zeroes and decide to >leave the cluster unallocated (see for example the "detect_zeroes" >option, or the "WRITE SAME" SCSI command). > - The qcow2 file could have been converted at some point, and >zero-filled clusters could have been deallocated for efficiency. > Berto Thank for every replay,and I understand completely . Then I look forward to using the “subcluster allocation ”feature as early as possible. Yang.bin
Re: [Qemu-discuss] qcow2 performanceimprove
>>>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. >>>If not fill zeroes and only write guest data ,what`s wrong could>> >>>happen ?>The following could happen:> 1) Guest reads at offset [0, 4k] -> >>>there's only zeroes> 2) Guest writes at offset [8k, 16k]> 3) Guest reads at >>>offset [0, 4k] -> there's something else now>Berto Why could guest read the area at offset [0, 4k] has not be writen yet ? Yang.bin
Re: [Qemu-discuss] qcow2 performance improve
> > > > 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. If not fill zeroes and only write guest data ,what`s wrong could happen ? >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
