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

From: Max Reitz <mreitz@redhat.com>
To: Pavel Butsykin <pbutsykin@virtuozzo.com>,
	Eric Blake <eblake@redhat.com>,
	qemu-block@nongnu.org, qemu-devel@nongnu.org
Cc: kwolf@redhat.com, armbru@redhat.com
Subject: Re: [Qemu-devel] [PATCH 0/2] Add reduce image for qcow2
Date: Wed, 31 May 2017 18:03:37 +0200	[thread overview]
Message-ID: <9b82b36b-e186-c493-ece4-28f027505ae7@redhat.com> (raw)
In-Reply-To: <a3ee5a6d-b16f-c4fd-b66e-da80d06f30a9@virtuozzo.com>

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

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

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