[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 0/4] qemu-img: add max-size subcommand
From: |
Nir Soffer |
Subject: |
Re: [Qemu-devel] [RFC 0/4] qemu-img: add max-size subcommand |
Date: |
Sat, 4 Mar 2017 00:15:00 +0200 |
On Sat, Mar 4, 2017 at 12:02 AM, John Snow <address@hidden> wrote:
>
>
> On 03/03/2017 04:38 PM, Nir Soffer wrote:
>> On Fri, Mar 3, 2017 at 3:51 PM, Stefan Hajnoczi <address@hidden> 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
>>>
>
- [Qemu-devel] [RFC 2/4] raw-format: add bdrv_max_size() support, (continued)
- [Qemu-devel] [RFC 2/4] raw-format: add bdrv_max_size() support, Stefan Hajnoczi, 2017/03/03
- [Qemu-devel] [RFC 3/4] qemu-img: add max-size subcommand, Stefan Hajnoczi, 2017/03/03
- [Qemu-devel] [RFC 4/4] iotests: add test 178 for qemu-img max-size, Stefan Hajnoczi, 2017/03/03
- Re: [Qemu-devel] [RFC 0/4] qemu-img: add max-size subcommand, John Snow, 2017/03/03
- Re: [Qemu-devel] [RFC 0/4] qemu-img: add max-size subcommand, Nir Soffer, 2017/03/03
- Re: [Qemu-devel] [RFC 0/4] qemu-img: add max-size subcommand, Daniel P. Berrange, 2017/03/07