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

[Kevin Wolf]

Am 18.05.2017 um 14:22 hat Denis V. Lunev geschrieben:
> 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:
>   [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.

Okay. If the existing tools can't give you the numbers that you need,
I think we could easily add this number to qemu-img check.

However, is this really what you need or do you want to know the image
size if the image was converted into a new image file? Because in this
case, some metadata (refcount blocks) might go away as well. In this
case, it sounds like Stefan's 'qemu-img measure' patches could be useful
for you (I haven't looked at them in detail yet, but that's what I
understood from the high level overview).

Kevin