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

Nir Soffer nsoffer at redhat.com
Sat May 29 22:47:12 UTC 2021



נשלח מה-iPhone שלי

> ‫ב-27 במאי 2021, בשעה 21:02, ‏‏Eric Blake ‏<eblake at 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 worried
> we 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20210530/ab98489f/attachment.htm>


More information about the Libguestfs mailing list