[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-discuss] [Qemu-devel] Estimation of qcow2 image size converted
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-discuss] [Qemu-devel] Estimation of qcow2 image size converted from raw image |
Date: |
Wed, 15 Feb 2017 15:14:19 +0000 |
User-agent: |
Mutt/1.7.1 (2016-10-04) |
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
Re: [Qemu-discuss] [Qemu-devel] Estimation of qcow2 image size converted from raw image, Nir Soffer, 2017/02/15