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
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.
Stefan
signature.asc
Description: PGP signature
