From: Kevin Wolf <kwolf@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, eblake@redhat.com,
armbru@redhat.com, mreitz@redhat.com, den@openvz.org
Subject: Re: [Qemu-devel] [PATCH] qcow2: add allocated-size to image specific info
Date: Thu, 18 May 2017 14:10:26 +0200 [thread overview]
Message-ID: <20170518121026.GF4646@noname.redhat.com> (raw)
In-Reply-To: <4f9deae2-c489-9681-83d3-e878adb33946@virtuozzo.com>
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 <vsementsov@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
next prev parent reply other threads:[~2017-05-18 12:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-18 10:09 [Qemu-devel] [PATCH] qcow2: add allocated-size to image specific info Vladimir Sementsov-Ogievskiy
2017-05-18 10:25 ` Kevin Wolf
2017-05-18 10:38 ` Denis V. Lunev
2017-05-18 11:04 ` Vladimir Sementsov-Ogievskiy
2017-05-18 12:10 ` Kevin Wolf [this message]
2017-05-18 12:22 ` Denis V. Lunev
2017-05-18 14:54 ` Kevin Wolf
2017-05-18 15:02 ` Denis V. Lunev
2017-05-18 12:33 ` Vladimir Sementsov-Ogievskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170518121026.GF4646@noname.redhat.com \
--to=kwolf@redhat.com \
--cc=armbru@redhat.com \
--cc=den@openvz.org \
--cc=eblake@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).