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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
