On 05/31/2017 09:43 AM, Pavel Butsykin wrote: > This patch adds the reduction of the image file for qcow2. As a result, this > allows us to reduce the virtual image size and free up space on the disk > without > copying the image. Image can be fragmented and reduction is done by punching > holes in the image file. > > # ./qemu-img create -f qcow2 -o size=4G image.qcow2 > Formatting 'image.qcow2', fmt=qcow2 size=4294967296 encryption=off > cluster_size=65536 lazy_refcounts=off refcount_bits=16 > > # ./qemu-io -c "write -P 0x22 0 1G" image.qcow2
So this is 1G of guest-visible data... > # ./qemu-img resize image.qcow2 128M > Image resized. ...and you are truncating the image by throwing away guest-visible content, with no warning or double-checking (such as requiring a -f force parameter or something) about the data loss. Shrinking images is something we should allow, but it feels like is a rare enough operation that you don't want it to be casually easy to throw away data. Is it feasible to require that a shrink operation will not be performed unless all clusters being eliminated have been previously discarded (or maybe written to zero), as an assurance that the guest did not care about the tail of the image? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
