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? >> 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 >>> >