Re: [PATCH v3 0/4] Additional parameters for qemu_img map

[Eric Blake <eblake@redhat.com>]

On 5/13/20 8:36 AM, Eyal Moscovici wrote:
> Hi,
> 
> The following series adds two parameters to qemu-img map:
> 1. start-offset: mapping starting offset.
> 2. max-length: the length of the mapping.
> 
> These parameters proved useful when mapping large disk spread across
> long store file chains. It allows us to bound the execution time of each
> qemu-img map execution as well as recover from failed mapping
> operations. In addition the map operation can divided to
> multiple independent tasks.
> 
> V3 changes:
> 1. Add cvtnum_full and made cvtnum a wrapper function.
> 2. Keep the original boundaries checks.
> 3. Tone down error messages.

While this does not directly touch NBD code, I find it quite handy for 
my tests of incremental backups over NBD (since I frequently use 
x-dirty-bitmap coupled with qemu-img map to read bitmaps, and subsetting 
the output is indeed nice), so I'll queue this through my NBD tree.  It 
may be another week or so before I send a pull request including this 
and other collected patches.

Congratulations on your first qemu contribution!

>  qemu-img.c                 | 76 +++++++++++++++++---------------------
>  tests/qemu-iotests/049.out |  8 ++--
>  2 files changed, 38 insertions(+), 46 deletions(-)

This series diffstat is off; later in the series, in 4/4, I see:

>  docs/tools/qemu-img.rst |  2 +-
>  qemu-img-cmds.hx        |  4 ++--
>  qemu-img.c              | 22 +++++++++++++++++++++-
>  3 files changed, 24 insertions(+), 4 deletions(-)

What I don't see is any iotest coverage of the new options, to ensure 
they don't regress.  Either a new iotest, or an enhancement to an 
existing iotest.  If you feel up to the task, post a 5/4 patch; if not, 
I'll probably enhance 223 (my x-dirty-bitmap reading code mentioned above).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org