[Libguestfs] [PATCH libnbd] api: Get rid of nbd_connection.

Eric Blake eblake at redhat.com
Thu May 23 18:26:51 UTC 2019


On 5/23/19 10:03 AM, Richard W.M. Jones wrote:
> This isn't quite finished because not all of the tests or examples
> have been updated, but it demonstrates an idea: Should we forget about
> the concept of having multiple connections managed under a single
> handle?

It makes sense to me.

As you discovered, the whole notion of multi-conn is tricky enough (we
can't learn if it is safe on a read-write connection until after the
first connect; do we block if one of the connections is not up; what
happens if the connections are not identical after all), and not adding
enough value (our sync APIs were holding a lock so that round-robins
were still serialized, and someone wanting performance is going to use
async anyways, but async already had to handle per-connection details
which is no different from per-handle details).

> 
> In this patch there is a single ‘struct nbd_handle *’ which manages a
> single state machine and connection (and therefore no nbd_connection).
> To connect to a multi-conn server you must do something like:
> 
>  - Connect once, check if the server supports multi-conn.
> 
>  - If it does, either disconnect and connect mulitple times "for
>    real", or else open further handles as required.
> 
> An example of use of the new API can be found in
> examples/threaded-reads-and-writes.c after this patch is applied.

It's a lot of churn, but we haven't released yet, and I am not finding
any strong reasons why we need to keep multi-conn embedded directly in
libnbd vs. having clients manage it themselves.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190523/5e054776/attachment.sig>


More information about the Libguestfs mailing list