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
