From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33107) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cjvTb-0006jZ-IF for qemu-devel@nongnu.org; Fri, 03 Mar 2017 17:15:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cjvTa-0005bC-C5 for qemu-devel@nongnu.org; Fri, 03 Mar 2017 17:15:03 -0500 Received: from mail-ot0-x242.google.com ([2607:f8b0:4003:c0f::242]:33932) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cjvTa-0005b2-7V for qemu-devel@nongnu.org; Fri, 03 Mar 2017 17:15:02 -0500 Received: by mail-ot0-x242.google.com with SMTP id x37so5609653ota.1 for ; Fri, 03 Mar 2017 14:15:02 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20170303135150.12145-1-stefanha@redhat.com> From: Nir Soffer Date: Sat, 4 Mar 2017 00:15:00 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [RFC 0/4] qemu-img: add max-size subcommand List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow Cc: Nir Soffer , Stefan Hajnoczi , Kevin Wolf , qemu-devel@nongnu.org, Maor Lipchuk , Alberto Garcia On Sat, Mar 4, 2017 at 12:02 AM, John Snow wrote: > > > On 03/03/2017 04:38 PM, Nir Soffer wrote: >> On Fri, Mar 3, 2017 at 3:51 PM, Stefan Hajnoczi 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 >>> >