All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nir Soffer <nsoffer@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: qemu-devel@nongnu.org, Eric Blake <eblake@redhat.com>,
	Kevin Wolf <kwolf@redhat.com>, Maor Lipchuk <mlipchuk@redhat.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	Alberto Garcia <berto@igalia.com>, John Snow <jsnow@redhat.com>
Subject: Re: [Qemu-devel] [RFC 0/4] qemu-img: add max-size subcommand
Date: Fri, 3 Mar 2017 23:38:17 +0200	[thread overview]
Message-ID: <CAMRbyysV54S0Sn42WuYFKfNSTMzQxk1yf1PSdrYXSUhiVr9Jjg@mail.gmail.com> (raw)
In-Reply-To: <20170303135150.12145-1-stefanha@redhat.com>

On Fri, Mar 3, 2017 at 3:51 PM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>
> RFCv1:
>  * Publishing patch series with just raw support, no qcow2 yet.  Please review
>    the command-line interface and let me know if you are happy with this
>    approach.
>
> Users and management tools sometimes need to know the size required for a new
> disk image so that an LVM volume, SAN LUN, etc can be allocated ahead of time.
> Image formats like qcow2 have non-trivial metadata that makes it hard to
> estimate the exact size without knowledge of file format internals.
>
> This patch series introduces a new qemu-img subcommand that calculates the
> required size for both image creation and conversion scenarios.
>
> The conversion scenario is:
>
>   $ qemu-img max-size -f raw -O qcow2 input.img
>   107374184448

Isn't this the minimal size required to convert input.img?

>
> Here an existing image file is taken and the output includes the space required
> for data from the input image file.
>
> The creation scenario is:
>
>   $ qemu-img max-size -O qcow2 --size 5G
>   196688

Again, this is the minimal size.

So maybe use min-size?

Or:

    qemu-img measure -f raw -O qcow2 input.img

Works nicely with other verbs like create, convert, check.

Now about the return value, do we want to return both the minimum size
and the maximum size?

For ovirt use case, we currently calculate the maximum size by multiplying
by 1.1. We use this when doing automatic extending of ovirt thin provisioned
disk. We start with 1G lv, and extend it each time it becomes full, stopping
when we reach virtual size * 1.1. Using more accurate calculation instead
can be nicer.

So we can retrun:

{
    "min-size": 196688,
    "max-size": 5905580032
}

Anyway thanks for working on this!

>
> Stefan Hajnoczi (4):
>   block: add bdrv_max_size() API
>   raw-format: add bdrv_max_size() support
>   qemu-img: add max-size subcommand
>   iotests: add test 178 for qemu-img max-size
>
>  include/block/block.h      |   2 +
>  include/block/block_int.h  |   2 +
>  block.c                    |  37 +++++++++
>  block/raw-format.c         |  16 ++++
>  qemu-img.c                 | 196 +++++++++++++++++++++++++++++++++++++++++++++
>  qemu-img-cmds.hx           |   6 ++
>  tests/qemu-iotests/178     |  75 +++++++++++++++++
>  tests/qemu-iotests/178.out |  25 ++++++
>  tests/qemu-iotests/group   |   1 +
>  9 files changed, 360 insertions(+)
>  create mode 100755 tests/qemu-iotests/178
>  create mode 100644 tests/qemu-iotests/178.out
>
> --
> 2.9.3
>

  parent reply	other threads:[~2017-03-03 21:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-03 13:51 [Qemu-devel] [RFC 0/4] qemu-img: add max-size subcommand Stefan Hajnoczi
2017-03-03 13:51 ` [Qemu-devel] [RFC 1/4] block: add bdrv_max_size() API Stefan Hajnoczi
2017-03-07 10:27   ` Alberto Garcia
2017-03-03 13:51 ` [Qemu-devel] [RFC 2/4] raw-format: add bdrv_max_size() support Stefan Hajnoczi
2017-03-07 10:32   ` Alberto Garcia
2017-03-10  4:33     ` Stefan Hajnoczi
2017-03-03 13:51 ` [Qemu-devel] [RFC 3/4] qemu-img: add max-size subcommand Stefan Hajnoczi
2017-03-03 21:56   ` Nir Soffer
2017-03-10  4:42     ` Stefan Hajnoczi
2017-03-03 13:51 ` [Qemu-devel] [RFC 4/4] iotests: add test 178 for qemu-img max-size Stefan Hajnoczi
2017-03-03 20:48 ` [Qemu-devel] [RFC 0/4] qemu-img: add max-size subcommand John Snow
2017-03-03 21:38 ` Nir Soffer [this message]
2017-03-03 22:02   ` John Snow
2017-03-03 22:15     ` Nir Soffer
2017-03-04  0:14       ` Nir Soffer
2017-03-10  7:58       ` Stefan Hajnoczi
2017-03-07 10:36 ` Daniel P. Berrange
2017-03-07 12:11   ` Alberto Garcia
2017-03-07 12:25     ` Daniel P. Berrange

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=CAMRbyysV54S0Sn42WuYFKfNSTMzQxk1yf1PSdrYXSUhiVr9Jjg@mail.gmail.com \
    --to=nsoffer@redhat.com \
    --cc=berrange@redhat.com \
    --cc=berto@igalia.com \
    --cc=eblake@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mlipchuk@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.