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
On Fri, Aug 17, 2018 at 10:28:49AM +0800, yang.bi...@zte.com.cn wrote: > > > > 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
Re: [Qemu-discuss] qcow2 performanceimprove
On 17/08/2018 04:28, yang.bi...@zte.com.cn wrote: 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 Because on any real computer (which qemu emulates), you can read any sector of a disk, even if it only contains whatever the disk factory put there during manufacture, usually something like 0x00, 0xA5, 0xFF etc. qcow2 unallocated virtual disk clusters contain 0x00 when read and there are commands that convert all-0x00 clusters back to being unallocated. So if a a guest machine issues a write to only part of a qcow2 unallocated cluster, the qcow2 needs to emulate that the rest of that qcow2 cluster still contains the 0x00. qcow2 might do that either by actually writing 0x00 to wherever it now allocated a full qcow2 cluster of storage in order to save the changed part, or create a complex data structure to remember which part of which cluster is virtually zero but not actually stored anywhere. Either way has speed overhead, but the first is usually the fastest. Now if the qcow2 file is created with the same qcow2 cluster size as the actual cluster size in the guest filesystem, and the start of the guest file system is aligned so all filesystem clusters start at disk offsets that are multiples of the filesystem cluster size (already required for physical disks with 4096-byte sectors), then this partial write scenario will happen vary rarely. That cluster size to cluster size alignment is generally a best practice for performance of thin provisioned virtual disks of all kinds, not just for qcow2 or other qemu formats. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
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