[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH] qcow2: add allocated-size to image specific inf

From: Denis V. Lunev
Subject: Re: [Qemu-block] [PATCH] qcow2: add allocated-size to image specific info
Date: Thu, 18 May 2017 15:22:24 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

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 <address@hidden>
>>>> ---
>>>> 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:
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
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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]