On Tue, Sep 29, 2020 at 09:44:49AM -0500, Eric Blake wrote:
On 9/29/20 9:37 AM, Richard W.M. Jones wrote:
> On Tue, Sep 29, 2020 at 06:51:06AM -0500, Eric Blake wrote:
>> On 9/29/20 6:23 AM, Richard W.M. Jones wrote:
>>> This is not related to the current patch, but generally for libnbd:
>>>
>>> (1) Should we be testing interop separately for qemu-storage-daemon
>>> (qsd), or is qsd basically qemu-nbd in a new wrapper so it's not worth
>>> doing it?
>
> Any thoughts on this one?
It's a new wrapper, but using the same qemu NBD server code under the
hood. Testing it might be good for demonstrating example command lines,
but won't tease out any new behavior interactions.
I might have a go at adding one test in that case, thanks.
Command line looks simple enough to use.
>>> (2) I found a bug in the new nbdinfo behaviour:
>>>
>>> $ nbdkit -fv file dir=/scratch
>>>
>>> (where /scratch is a directory with a lot of files in it)
>>>
>>> $ nbdinfo --version
>>> libnbd 1.5.3
>>> $ nbdinfo --list nbd://localhost
>>> [... lots of files shown ...]
>>> nbd_opt_info: recv: Connection reset by peer
>>>
>>> nbdkit gives this error:
>>>
>>> nbdkit: file[1]: error: client exceeded maximum number of options (32)
>>
>> Yeah, we really ought to raise nbdkit's limits when .list_exports
>> returns a large list. We haven't yet released nbdkit 1.24 where the
>> file driver actually has a large .list_exports; but it may also be a
>> reason to figure out if libnbd should go to the effort of
>> re-connecting for the later portion of a list on servers like older
>> nbdkit that limit the length of the negotiation phase.
>
> It raises the question about what the limit needs to be. If I point
> nbdkit-file-plugin at a directory, the number of exports could be
> pretty much unlimited. But at the smae time the options limit is
> there for a fairly good reason. Should we change the client to
> request info in groups of <N> (presumably requiring reconnection)?
I posted an nbdkit patch for upping the limit that nbdkit allows, as
'qemu-nbd --list' is also able to trigger the current low limit.
Changing nbdinfo to process in groups of N is lots of code for little
benefit, especially if we can't find any other server that has a limit
as low as the old nbdkit had (remember, it's not until nbdkit 1.24 that
you can come up with an export list long enough to worry about the old
limit).
OK, agreed, thanks!
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html