[Libguestfs] [PATCH libnbd v2 1/6] api: Synchronous connect waits til all connections are connected.

[Eric Blake]

On 5/22/19 9:21 PM, Eric Blake wrote:

> On IRC we were chatting about how multi-conn > 1 makes no sense with
> connect_command() (where we are limited to exactly one channel over
> stdin/stdout), so it may also be worth adding some logic to have
> connect_command fail if set_multi_conn is > 1, and to likewise have
> set_multi_conn(2) fail if the existing connection is already started in
> command mode (do we even track which mode a commands started in, and/or
> insist that all connections used the same nbd_connect_*? Or can you
> mix-and-match a TCP and a Unix socket into a multi-conn struct nbd_handle?)

Thinking a bit more - there may be clients that want multi-pathing
effects (call out to different servers each serving identical data - if
any one connection goes down, the rest are still up) - so at least in
the aio interface, allowing second connections to use a different socket
address than the first makes sense, at which point mix-and-match of Unix
and TCP makes sense. There's also an interesting observation: for
writable connections, you really want to avoid multi-conn unless the
server advertises NBD_FLAG_MULTI_CONN (otherwise, things are not cache
consistent, and by the time you serialize overlapping requests yourself
to work around that, you haven't gained any benefits). But for read-only
connections, even if the server did not advertise NBD_FLAG_MULTI_CONN
(and qemu-nbd doesn't yet, although it should), it may still work out to
attempt multi-conn anyways.  Sadly, this also means that can_multi_conn
based on eflags is not a reliable witness of whether a second attempt at
connecting will succeed or fail (you really have to know in advance
whether the server will accept parallel connections if it didn't advertise).

> At any rate, I don't think we're done with the design in this area.

This still holds.

-- 
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/20190522/45eb2efd/attachment.sig>