On 2017-05-31 17:54, Pavel Butsykin wrote: > On 31.05.2017 18:03, Eric Blake wrote: >> 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. > > It is assumed that the user has already made a preparatory with the > image: > 1. freeing space at the end of the image > 2. reducing the last partition on the disk > 3. rebuilding fs > Only after these steps, the user can reduce the image by qemu-img.
But your implementation allows the user to reduce it anyway, even if these steps have not been performed. I very much agree that we have to be careful because otherwise you might ruin all your data if you hand-type a resize command and drop a digit. > I think it's not so rare case, sometimes people run out of disk space > and this is another way to solve the problem (along with the use of > trim). > > We already have all the interfaces, left them only to support :) > >> 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? >> > > Yes. > > # ./qemu-img create -f qcow2 -o size=4G image.qcow2 > > # ./qemu-io -c "write -P 0x22 0 1G" image.qcow2 > # ./qemu-io -c "write -P 0x22 1G 1G" image.qcow2 > > # qemu-img map ./image.qcow2 > Offset Length Mapped to File > 0 0x20000000 0x50000 ./image.qcow2 > 0x20000000 0x20000000 0x20060000 ./image.qcow2 > 0x40000000 0x20000000 0x40070000 ./image.qcow2 > 0x60000000 0x20000000 0x60080000 ./image.qcow2 > > # ./qemu-io -c "discard 1G 1G" ./image.qcow2 > > # qemu-img map ./image.qcow2 > Offset Length Mapped to File0 0x20000000 > 0x50000 ./image.qcow2 > 0x20000000 0x20000000 0x20060000 ./image.qcow2 No, it isn't, because qemu-io is a debugging tool and a debugging tool only. We could require the user to perform a trim operation or something in the guest instead -- but I'd prefer a plain new flag for qemu-img resize that says the user is OK with shrinking the image and thus throwing data way. I think it's fine to have this flag only as part of the qemu-img interface, not e.g. for the block-resize QMP command. I think it's reasonable to assume someone sending a QMP command (i.e. usually the management layer) to know exactly what they are doing. OTOH, I wouldn't oppose a flag there, though, I just don't think it's absolutely necessary. Max
signature.asc
Description: OpenPGP digital signature
