On 2017-08-22 01:31, John Snow wrote: > > > On 08/17/2017 05:15 AM, Pavel Butsykin wrote: >> This patch add shrinking 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 shrink is done by punching >> holes >> in the image file. >> >> # ./qemu-img create -f qcow2 image.qcow2 4G >> 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 >> wrote 1073741824/1073741824 bytes at offset 0 >> 1 GiB, 1 ops; 0:00:04.59 (222.886 MiB/sec and 0.2177 ops/sec) >> >> # ./qemu-img resize image.qcow2 512M >> warning: qemu-img: Shrinking an image will delete all data beyond the >> shrunken image's end. Before performing such an operation, make sure there >> is no important data there. >> error: qemu-img: Use the --shrink option to perform a shrink operation. >> >> # ./qemu-img resize --shrink image.qcow2 128M >> Image resized. >> >> # ./qemu-img info image.qcow2 >> image: image.qcow2 >> file format: qcow2 >> virtual size: 128M (134217728 bytes) >> disk size: 128M >> cluster_size: 65536 >> Format specific information: >> compat: 1.1 >> lazy refcounts: false >> refcount bits: 16 >> corrupt: false >> >> # du -h image.qcow2 >> 129M image.qcow2 >> > > It looks sane to me, and already has a full set of R-Bs from Max. Are we > waiting for Kevin?
We were waiting for Kevin to handle 2.10 patches so he could go into PTO and for me to come back from PTO. ;-) I'm still sifting through my inbox... When I'm done, I'll take a look, but I have no idea how long that might last. (Since 2.10 isn't out yet, there might be more pressing issues still...? I don't quite now yet, to be honest...) > It looks like in Vladimir's series we sidestepped the problem of what > happens if we resize with persistent bitmaps: we deny the operation, > regardless of if we are shrinking, growing, or have bitmaps that are > read-only, frozen, or what-have-you. > > It shouldn't be too hard to add soon, but this is fine for now. > (I think for adding it we just need to make sure the bitmaps aren't > frozen and are not read-only, and the implementation bitmap structure > can already handle truncation in either direction just fine.) > > Anyway; > > Reviewed-by: John Snow <js...@redhat.com> Thanks, in any case. :-) Max
signature.asc
Description: OpenPGP digital signature
