Re: [Libguestfs] [PATCH libnbd v2 1/6] api: Synchronous connect waits til all connections are connected.
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
Attachments:
- signature.asc (application/pgp-signature — 488 bytes)