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

From: Max Reitz <mreitz@redhat.com>
To: "Denis V. Lunev" <den@openvz.org>, Kevin Wolf <kwolf@redhat.com>,
	Eric Blake <eblake@redhat.com>
Cc: armbru@redhat.com, qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Pavel Butsykin <pbutsykin@virtuozzo.com>
Subject: Re: [Qemu-devel] [PATCH 0/2] Add reduce image for qcow2
Date: Wed, 7 Jun 2017 15:37:56 +0200	[thread overview]
Message-ID: <b1171a15-72c2-ca25-2d7b-e0abde8a71f3@redhat.com> (raw)
In-Reply-To: <8baa473d-d756-2a0b-3356-1cc00f31bd25@openvz.org>

[-- Attachment #1: Type: text/plain, Size: 3157 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 498 bytes --]