qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/2] Add reduce image for qcow2


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 0/2] Add reduce image for qcow2
Date: Thu, 1 Jun 2017 11:12:24 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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.

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.

Kevin

Attachment: pgp6P8A5PCcFo.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]