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

[Richard W.M. Jones]

On Wed, Nov 27, 2019 at 08:06:43PM +0200, Nir Soffer wrote:
> I have a failing test[1] of ovirt-imageio nbd client[2], getting
> base:allocation from qemu-nbd.
> 
> The failing test is:
> 
> def test_base_allocation_some_data(nbd_server, user_file):
>     nbd_server.image = user_file.path
>     size = 1024**3
>     data_length = 4096
>     zero_length = size // 2 - data_length
> 
>     with io.open(nbd_server.image, "wb") as f:
>         f.truncate(size)
>         f.write(b"x" * data_length)
>         f.seek(zero_length, os.SEEK_CUR)
>         f.write(b"x" * data_length)
> 
>     nbd_server.start()
> 
>     with nbd.open(nbd_server.url) as c:
>         extents = c.extents(0, size)
> 
>         assert extents == {
>             "base:allocation": [
>                 nbd.Extent(data_length, False),
>                 nbd.Extent(zero_length, True),
>                 nbd.Extent(data_length, False),
>                 nbd.Extent(zero_length, True),
>             ]
>         }
> 
> The test fails because on CentOS 8, qemu-nbd returns:
> 
>     {'base:allocation': [Extent(length=4096, zero=False)]}
> 
> 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

Could it be this fix which appeared in 3.1.0?

commit fb7afc797e071f2616e1ccc849b39fe43e7033bf
Author: Vladimir Sementsov-Ogievskiy <address@hidden>
Date:   Wed Jul 4 14:23:02 2018 +0300

    nbd/server: send more than one extent of base:allocation context
    
    This is necessary for efficient block-status export, for clients which
    support it.  (qemu is not yet such a client, but could become one.)
    
    Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
    Message-Id: <address@hidden>
    [eblake: grammar tweaks]
    Signed-off-by: Eric Blake <address@hidden>

> 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?

As you say, the NBD protocol only guarantees that the client will make
forward progress (ie. that at least 1 byte of information is returned
by the server), so strictly speaking this is not a violation of the
protocol even though it was a bug in qemu-nbd.

No idea if we're going to or even if we can fix this in RHEL non-AV or
CentOS.

> Looks like I need to change the test to do multiple calls until the
> entire we have
> reponse for the entire range.
> 
> [1] https://travis-ci.org/nirs/ovirt-imageio/jobs/617732045
> [2] https://gerrit.ovirt.org/c/105126
> 
> Nir

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top