On 2017-06-01 13:11, Denis V. Lunev wrote: > On 06/01/2017 12:12 PM, Kevin Wolf wrote: >> Am 31.05.2017 um 17:03 hat Eric Blake geschrieben: >>> 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? >> I think that ship has sailed long ago because raw images have always >> supported shrinking images without any special checks or options. We >> want consistency between raw and qcow2, and we also need to provide >> backwards compatibility. >> >> The only thing I can imagine we could do now is to introduce a --shrink >> option in qemu-img, print a deprecation warning for shrinking without >> this option, and then make it mandatory in a few years.
Do I hear a "3.0"? >> If we want to distinguish based on the block driver, so that we can >> require --shrink for all drivers that didn't support shrinking until >> now, we'd have to check the .bdrv_truncate() implementations of all >> drivers to see whether it already allowed shrinking. We could have an ugly raw-only hack directly in qemu-img (and qmp_block_resize) until 3.0. I'm really concerned about someone mistyping something and accidentally dropping a digit. >> Kevin > Will the solution proposed by Pavel in the answer to Max work: > - if there are no data blocks in the truncated space, truncate is allowed > without additional options > - if there are data blocks in the truncated space, truncate is allowed > with the flag --force or error is generated I'd be OK with that, but I'm not sure we really need it. It would be nice to have for convenience, but I don't think it solves the backwards-compatibility problem (as said by Kevin), and I'm not sure it makes things that much more convenient: Just specifying --force is easier than to manually trim the device in the guest (and then maybe having to specify --force anyway because you didn't do it right). Max
signature.asc
Description: OpenPGP digital signature