Re: [Qemu-devel] Estimation of qcow2 image size converted from raw image

[Stefan Hajnoczi <stefanha@gmail.com>]

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

On Wed, Feb 15, 2017 at 05:49:58PM +0200, Nir Soffer wrote:
> On Wed, Feb 15, 2017 at 5:14 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > On Mon, Feb 13, 2017 at 05:46:19PM +0200, Maor Lipchuk wrote:
> >> I was wondering if that is possible to provide a new API that
> >> estimates the size of
> >> qcow2 image converted from a raw image. We could use this new API to
> >> allocate the
> >> size more precisely before the convert operation.
> >>
> > [...]
> >> We think that the best way to solve this issue is to return this info
> >> from qemu-img, maybe as a flag to qemu-img convert that will
> >> calculate the size of the converted image without doing any writes.
> >
> > Sounds reasonable.  qcow2 actually already does some of this calculation
> > internally for image preallocation in qcow2_create2().
> >
> > Let's try this syntax:
> >
> >   $ qemu-img query-max-size -f raw -O qcow2 input.raw
> >   1234678000
> 
> This is little bit verbose compared to other commands
> (e.g. info, check, convert)
> 
> Since this is needed only during convert, maybe this can be
> a convert flag?
> 
>     qemu-img convert -f xxx -O yyy src dst --estimate-size --output json
>     {
>         "estimated size": 1234678000
>     }

What is dst?  It's a dummy argument.

Let's not try to shoehorn this new sub-command into qemu-img convert.

> > As John explained, it is only an estimate.  But it will be a
> > conservative maximum.
> >
> > Internally BlockDriver needs a new interface:
> >
> > struct BlockDriver {
> >     /*
> >      * Return a conservative estimate of the maximum host file size
> >      * required by a new image given an existing BlockDriverState (not
> >      * necessarily opened with this BlockDriver).
> >      */
> >     uint64_t (*bdrv_query_max_size)(BlockDriverState *other_bs,
> >                                     Error **errp);
> > };
> >
> > This interface allows individual block drivers to probe other_bs in
> > whatever way necessary (e.g. querying block allocation status).
> >
> > Since this is a conservative max estimate there's no need to read all
> > data to check for zero regions.  We should give the best estimate that
> > can be generated quickly.
> 
> I think we need to check allocation (e.g. with SEEK_DATA), I hope this
> is what you mean by not read all data.

Yes, allocation data must be checked.  But it will not read data
clusters from disk to check if they contains only zeroes.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]