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: Max Reitz
Subject: Re: [Qemu-devel] [PATCH 0/2] Add reduce image for qcow2
Date: Wed, 7 Jun 2017 15:37:56 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0

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: signature.asc
Description: OpenPGP digital signature


reply via email to

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