On Sat, Mar 4, 2017 at 12:15 AM, Nir Soffer <nir...@gmail.com> 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.
Thinking more about this, max-size is correct for this use case, the maximum size of the image, used as the minimal allocation. > >> >>>> >>>> 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? > >>> 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. > > Nir > >> >> --js >> >>>> >>>> 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 >>>> >>