Re: [Libguestfs] [PATCH libnbd 3/3] copy: Update nbdcopy(1) about multiple connections

On Thu, May 27, 2021 at 02:07:19PM +0100, Richard W.M. Jones wrote: Changing the default to allow multiple writers may risky; I'm worried we may be stuck with always having to opt-in to it. On the other hand, if qemu-nbd advertises multi-conn only when --shared=N for N>1, we'd have a nice witness for when we can use multi-conn (but only after qemu 6.1 or downstream backports of this as-yet unwritten patch). Other ideas: Add an NBD_OPT extension to allow a client to inform the server of its intent to perform non-overlapping parallel I/O. If the server understands the new option, it can then proceed to allow additional connections (that is, make qemu-nbd dynamically turn on --shared=N based on a new-enough client requesting upload mode). Obviously wouldn't work until qemu 6.1 or downstream backports of the new feature. Add an NBD_OPT extension to allow a client to learn from the server how many connections it actually accepts (supporting a number > 1 even without multi-conn is viable). If the server answers, then use that many connections; if not, then stick to 1 connection unless multi-conn is set. Again, something that won't work out of the box until qemu 6.1 or downstream backports of the new feature. At any rate, looks like I need to accelerate my patches to have qemu-nbd advertise multi-conn for --shared=N writeable servers (where qemu itself should already be cache-consistent because it has proper serialization of any overlapping requests, regardless of which client is making the request). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org