Re: [Qemu-discuss] qcow2 performanceimprove

[Jakob Bohm]

On 17/08/2018 04:28, address@hidden 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