On 11/27/19 12:24 PM, Nir Soffer wrote:
On Wed, Nov 27, 2019 at 8:06 PM Nir Soffer <[email protected]> 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
