Re: [ovirt-devel] Disk sizes not updated on unmap/discard

[Kevin Wolf]

Am 02.10.2020 um 00:57 hat Nir Soffer geschrieben:
> After sparsifying disk:
> 
> storage:
> $ qemu-img check /var/tmp/download.qcow2
> No errors were found on the image.
> 170/163840 = 0.10% allocated, 0.59% fragmented, 0.00% compressed clusters
> Image end offset: 11927552
> 
> $ ls -lhs /home/target/2/00
> 2.1G -rw-r--r--. 1 root root 100G Oct  2 01:14 /home/target/2/00
> 
> host:
> 
> # qemu-img check
> /dev/27f2b637-ffb1-48f9-8f68-63ed227392b9/42cf66df-43ad-4cfa-ab57-a943516155d1
> No errors were found on the image.
> 170/163840 = 0.10% allocated, 0.59% fragmented, 0.00% compressed clusters
> Image end offset: 4822138880
> 
> Allocation decreased from 50% to 0.1%, but image end offset
> decreased only from 5381423104 to 4822138880 (-10.5%).
> 
> I don't know if this is a behavior change in virt-sparsify or qemu or
> it was always like that.
> 
> We had an old and unused sparsifyVolume API in vdsm before 4.4. This
> did not use --in-place and was very complicated because of this. But I
> think it would work in this case, since qemu-img convert will drop the
> unallocated areas.
> 
> For example after downloading the sparsified disk, we get:
> 
> $ qemu-img check download.qcow2
> No errors were found on the image.
> 170/163840 = 0.10% allocated, 0.59% fragmented, 0.00% compressed clusters
> Image end offset: 11927552
> 
> 
> Kevin, is this the expected behavior or a bug in qemu?
> 
> The disk I tested is a single qcow2 image without the backing file, so
> theoretically qemu can deallocate all the discarded clusters.

This is expected. Discard just frees the cluster whereever it is stored,
but it doesn't compact the image, i.e. move data at higher offsets to
lower offsets (which would be a rather expensive operation).

If your storage supports thin provisioning/hole punching (the most
common case of this is sparse files on a filesystem), then you can use
the freed space for something else. If it doesn't, it's just marked free
on the qcow2 level and future writes to the image will allocate the
freed space first instead of growing the image, but you won't be able to
use it for things outside of the image.

In contrast, 'qemu-img convert' starts with an empty file and only
writes what needs to be written, so it will result in a compacted image
file that doesn't have holes and is as short as it can be.

Kevin