From: "Daniel P. Berrange" <berrange@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: Maor Lipchuk <mlipchuk@redhat.com>,
qemu-devel@nongnu.org, qemu-discuss@nongnu.org,
Nir Soffer <nsoffer@redhat.com>, Kevin Wolf <kwolf@redhat.com>,
Allon Mureinik <amureini@redhat.com>,
Qemu-block <qemu-block@nongnu.org>
Subject: Re: [Qemu-devel] Estimation of qcow2 image size converted from raw image
Date: Mon, 13 Feb 2017 17:16:57 +0000 [thread overview]
Message-ID: <20170213171657.GI12387@redhat.com> (raw)
In-Reply-To: <c723ca77-2695-1915-fa9f-e1d868bed1db@redhat.com>
On Mon, Feb 13, 2017 at 12:03:35PM -0500, John Snow wrote:
> Also keep in mind that changing the cluster size will give you different
> answers, too -- but that different cluster sizes will effect the runtime
> performance of the image as well.
This means that apps trying to figure out this future usage have to
understand fine internal impl details of qcow2 to correctly calculate
it.
> > We think that the best way to solve this issue is to return this info
> > from qemu-img, maybe as a flag to qemu-img convert that will
> > calculate the size of the converted image without doing any writes.
> >
>
> Might not be too hard to add, but it wouldn't necessarily be any more
> accurate than if you implemented the same logic, I think.
>
> Still, it'd be up to us to keep it up to date, but I don't know what
> guarantees we could provide about the accuracy of the estimate or
> preventing it from bitrot if there are format changes..
As opposed to every application trying to implement the logic
themselves...it'll likely bitrot even worse in 3rd party apps
as their maintainers won't notice format changes until they
see a bug report. Likewise, app developers aren't in a much
better position wrt to accracy - if anything they'll do a worse
job at calculating it since they might miss subtable nuances of
the qcow2 format that qemu developers would more likely get right.
This isn't just a problem wrt to the usage scenario mentioned in
this thread. For active VMs, consider you want to determine whether
you are at risk of overcommitting the filesystem or not. You cannot
simply sum up the image capacity - you need to know the largest
size that the qcow2 file is going to grow to in future[1] - this
again requires the app to calculate overhead of qcow2 metdata to
understand what they've committed to providing in terms of storage
Regards,
Daniel
[1] There is no upper limit if internal snapshots are usedm but if
we assume use of external snapshots, we should be able to
calculate the file size commitment.
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
next prev parent reply other threads:[~2017-02-13 17:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-13 15:46 [Qemu-devel] Estimation of qcow2 image size converted from raw image Maor Lipchuk
2017-02-13 17:03 ` John Snow
2017-02-13 17:16 ` Daniel P. Berrange [this message]
2017-02-13 18:26 ` John Snow
2017-02-15 15:14 ` Stefan Hajnoczi
2017-02-15 15:20 ` Daniel P. Berrange
2017-02-15 15:34 ` Eric Blake
2017-02-15 15:57 ` Nir Soffer
2017-02-15 16:05 ` [Qemu-devel] [Qemu-discuss] " Alberto Garcia
2017-02-15 16:11 ` Daniel P. Berrange
2017-02-15 16:07 ` [Qemu-devel] " Daniel P. Berrange
2017-02-20 11:12 ` Stefan Hajnoczi
2017-02-15 15:49 ` Nir Soffer
2017-02-20 11:07 ` Stefan Hajnoczi
[not found] ` <CAJ1JNOdzD7DHTHGJEO2YQANDPq0kY-PEh6J1jBkP7hUW0Kvy9w@mail.gmail.com>
[not found] ` <CAMRbyyssi_rspwDJTtWM1Ju5CTZ15z1xBikRDONrS84rx+B8Qg@mail.gmail.com>
2017-02-22 16:15 ` Maor Lipchuk
2017-02-22 22:06 ` Maor Lipchuk
2017-02-28 9:19 ` Stefan Hajnoczi
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=20170213171657.GI12387@redhat.com \
--to=berrange@redhat.com \
--cc=amureini@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mlipchuk@redhat.com \
--cc=nsoffer@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-discuss@nongnu.org \
/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).