Re: [Qemu-devel] [PATCH] qcow2: add allocated-size to image specific info

["Denis V. Lunev" <den@openvz.org>]

On 05/18/2017 03:10 PM, Kevin Wolf wrote:
> Am 18.05.2017 um 13:04 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> 18.05.2017 13:25, Kevin Wolf wrote:
>>> Am 18.05.2017 um 12:09 hat Vladimir Sementsov-Ogievskiy geschrieben:
>>>> Shows, how much data qcow2 allocates in underlying file. This should
>>>> be helpful on non-sparse file systems, when qemu-img info "disk size"
>>>> doesn't provide this information.
>>>>
>>>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
>>>> ---
>>>> Hi all.
>>>>
>>>> Here is an allocated-size feature for qemu-img info.
>>> I'm not a fan of loading all L2 tables (can take some time) for
>>> 'qemu-img info' (which should be very quick). Why isn't the qemu-img
>>> check output good enough?
>>>
>>> Kevin
>>>
>>> $ ./qemu-img check /tmp/test.qcow2
>>> No errors were found on the image.
>>> 16164/491520 = 3.29% allocated, 11.98% fragmented, 0.00% compressed clusters
>>> Image end offset: 1060044800
>>> $ ./qemu-img check --output=json /tmp/test.qcow2
>>> {
>>>     "image-end-offset": 1060044800,
>>>     "total-clusters": 491520,
>>>     "check-errors": 0,
>>>     "allocated-clusters": 16164,
>>>     "filename": "/tmp/test.qcow2",
>>>     "format": "qcow2",
>>>     "fragmented-clusters": 1937
>>> }
>> It is not the same, it shows guest clusters, but we need host
>> clusters - including all metadata, dirty bitmaps, snapshots, etc..
> Ah, right. But isn't that exactly the "disk size" (actual-size in JSON)
> from qemu-img info? Your commit message mentions non-sparse filesystems
> (which one?), but why wouldn't "disk size" provide this information
> there?
>
> The one case where it doesn't work is if you store a qcow2 image on a
> raw block device (this is something that oVirt does). In that case,
> you can't benefit from sparseness and disk space is used for a cluster
> in the middle even if its refcount is 0. oVirt uses "image-end-offset"
> to get the size of the first of the block device that is actually in use
> by the image.
>
> What is your exact use case? Maybe this helps me understand the exact
> kind of information that you need.
>
> Kevin
Let us assume we have an image like the following:
  [0][1][2][3][4][5][6]
Here [N] represents guest block number N, i.e. there are
7 sequential guest blocks. Let us assume that the guest
issues TRIM and says that block [1] is not needed at all.
The image becomes like
  [0][.][2][3][4][5][6]
If the filesystem with this image is dumb and does not
support holes, we could not determine that we have
not used space inside the disk marked as [.]

The goal of this patch is to know amount of [.] blocks.

Den