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

[Pavel Butsykin]

On 31.05.2017 19:03, Max Reitz wrote:
> 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.

We could check that the shrinking part of the image doesn't contain
non-zero clusters and print just a warning. But on the other hand, if
the user has not performed trim, at the end of the disk will still be
dirty cluster and we can't force users to do trim :)

We can add a flag --force and without flag just print a warning.

> > 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.

I agree that the flag can be only as protection from the human factor.

> Max