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