On Sat, Mar 04, 2017 at 12:15:00AM +0200, Nir Soffer wrote: > On Sat, Mar 4, 2017 at 12:02 AM, John Snow <js...@redhat.com> wrote: > > > > > > On 03/03/2017 04:38 PM, Nir Soffer wrote: > >> On Fri, Mar 3, 2017 at 3:51 PM, Stefan Hajnoczi <stefa...@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? > >> > > > > It's an upper bound for the property being measured, which is current > > allocation size, not maximum potential size after growth. > > From my point of view, this is the minimal size you must allocate if you > want to convert the image to logical volume. > > > > >>> > >>> 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. > >> > > > > Measure what? This is strictly less descriptive even if "max-size" isn't > > a verb. > > measure-size?
You're right, the sub-command should be a verb.
> >> 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!
> >>
> >
> > It sounds like you want something different from what was intuited by
> > Maor Lipchuck. There are two things to estimate:
> >
> > (A) An estimate of the possible size of an image after conversion to a
> > different format, and
> > (B) An estimate of the possible size after full allocation.
> >
> > I got the sense that Maor was asking for (A), but perhaps I am wrong
> > about that. However, both are "maximums" in different senses.
>
> Both are minimum when you have to allocate the space.
>
> Maor ask about A because he is working on fixing allocation when
> converting existing files, but we also have other use cases like B.
Daniel Berrange is also interested in the size of a fully populated
image file. I'll expand the patch series to report both sizes.
Stefan
signature.asc
Description: PGP signature
