ב-27 במאי 2021, בשעה 21:02, Eric Blake <eblake@redhat.com> כתב/ה:
On Thu, May 27, 2021 at 02:07:19PM +0100, Richard W.M. Jones wrote:I want to see what Eric has to say about whether we can or should
change qemu-nbd.
Changing the default to allow multiple writers may risky; I'm worriedwe may be stuck with always having to opt-in to it.
Maybe it is better to avoid promising any default behavior. For example we can say that “nbdcopy may use multiple connections”.
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).
This seems to be the best option. It seems that emu-nbd already ready for this.
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
This sound too complicated for the common user.
(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).
I think this is needed anyway. Without this, if a remote qemu-nbd was started with —shared=2 nbdcopy will deadlock trying to connect 4 times.
We can change nbdcopy to avoid the deadlock but using server limit would be much simpler and will help all nbd clients.
If we return more detailed info about multiple connections, we can also report the “isolation” level supported by the server. For example qemu can report “full” since it does proper locking. Server without such locking can report that only non-overlapping writes are supported (“none”?).
We probably need to take this to nbd mailing list.
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).
Do you need any help to make this happen?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org