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