Re: qemu-nbd CMD_BLOCK_STATUS returns one extent in CentOS 8.0, all extents in 4.1.0 - is this a bug?

[Eric Blake]

On 11/27/19 12:24 PM, Nir Soffer wrote:
> On Wed, Nov 27, 2019 at 8:06 PM Nir Soffer <address@hidden> wrote:
> > I have a failing test[1] of ovirt-imageio nbd client[2], getting
> > base:allocation from qemu-nbd.

> Changing this to:
>
>          extents = []
>          pos = 0
>
>          while pos < size:
>              res = c.extents(pos, size - pos)["base:allocation"]
>              for ext in res:
>                  pos += ext.length
>                  extents.append(ext)
>
> Solves the issue:
> https://travis-ci.org/nirs/ovirt-imageio/jobs/617846324
>
> So I guess I answered my question but I would like to get
> your opinion anyway.

Correct, the behavior is spec-compliant, even if annoying that it 
doesn't make as much forward progress as is possible.  Writing a loop in 
the client is the correct behavior (the spec guarantees forward progress 
on success, so at least that aspect of writing a loop is easier).

> > We send CMD_BLOCK_STATUS with flags=0 (NBD_CMD_FLAG_REQ_ONE not set).
> >
> > The tests fail with:
> > qemu-img-2.12.0-65.module_el8.0.0+189+f9babebb.5.x86_64
> >
> > And work with:
> > qemu-img-4.1.0-5.fc30.x86_64
> >
> > It looks like qemu on the failing version return single extent instead
> > of all extents
> > in the requested range (offset=0, length=1g). Reading the NBD spec it seems like
> > the server is allowed to that, but since the behaviour is different in
> > 4.1.0, maybe
> > we are missing some patch in CentOS 8.0?

Very possible - a lot of NBD patches have gone in since upstream 2.12, 
and not all of them have been backported.

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