On 03/03/2017 08:51 AM, 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 > > 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 >
It looks sane to me, implementation looks clean enough. Thanks! > 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 >
