On 10/2/20 3:41 AM, Kevin Wolf wrote: >> 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.
Of course, writing a tool to defragment qcow2 files in-place is not a bad idea, if someone wants a potentially fun project. But it's not the highest priority task (since copying to fresh storage gets the same effect, albeit with a temporarily larger storage requirement), so I won't hold my breath on someone jumping into such a task in the near future. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature