<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><br><div dir="rtl"><div style="text-align: right;direction: rtl; ">נשלח מה-iPhone שלי</div></div><div dir="rtl"><br><blockquote type="cite">ב-27 במאי 2021, בשעה 21:02, Eric Blake <eblake@redhat.com> כתב/ה:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>On Thu, May 27, 2021 at 02:07:19PM +0100, Richard W.M. Jones wrote:</span><br><blockquote type="cite"><span>I want to see what Eric has to say about whether we can or should</span><br></blockquote><blockquote type="cite"><span>change qemu-nbd.</span><br></blockquote><span></span><br><span>Changing the default to allow multiple writers may risky; I'm worried</span><br><span>we may be stuck with always having to opt-in to it.</span><br></div></blockquote><div><br></div><div>Maybe it is better to avoid promising any default behavior. For example we can say that “nbdcopy may use multiple connections”.</div><div><br></div><blockquote type="cite"><div dir="ltr"><span></span><br><span>On the other hand, if qemu-nbd advertises multi-conn only when</span><br><span>--shared=N for N>1, we'd have a nice witness for when we can use</span><br><span>multi-conn (but only after qemu 6.1 or downstream backports of this</span><br><span>as-yet unwritten patch).</span><br></div></blockquote><div><br></div><div>This seems to be the best option. It seems that emu-nbd already ready for this.</div><br><blockquote type="cite"><div dir="ltr"><span></span><span>Other ideas:</span><br><span></span><br><span>Add an NBD_OPT extension to allow a client to inform the server of its</span><br><span>intent to perform non-overlapping parallel I/O. If the server</span><br><span>understands the new option, it can then proceed to allow additional</span><br><span>connections </span></div></blockquote><div><br></div><div>This sound too complicated for the common user.</div><br><blockquote type="cite"><div dir="ltr"><span>(that is, make qemu-nbd dynamically turn on --shared=N</span><br><span>based on a new-enough client requesting upload mode). Obviously</span><br><span>wouldn't work until qemu 6.1 or downstream backports of the new feature.</span><br><span></span><br><span>Add an NBD_OPT extension to allow a client to learn from the server</span><br><span>how many connections it actually accepts (supporting a number > 1 even</span><br><span>without multi-conn is viable). </span></div></blockquote><div><br></div><div>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.</div><div><br></div><div>We can change nbdcopy to avoid the deadlock but using server limit would be much simpler and will help all nbd clients.</div><div><br></div><div>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”?).</div><div><br></div><div>We probably need to take this to nbd mailing list.</div><div><br></div><blockquote type="cite"><div dir="ltr"><span> If the server answers, then use that</span><br><span>many connections; if not, then stick to 1 connection unless multi-conn</span><br><span>is set. Again, something that won't work out of the box until qemu</span><br><span>6.1 or downstream backports of the new feature.</span><br><span></span><br><span>At any rate, looks like I need to accelerate my patches to have</span><br><span>qemu-nbd advertise multi-conn for --shared=N writeable servers (where</span><br><span>qemu itself should already be cache-consistent because it has proper</span><br><span>serialization of any overlapping requests, regardless of which client</span><br><span>is making the request).</span><br></div></blockquote><div><br></div><div>Do you need any help to make this happen?</div><br><blockquote type="cite"><div dir="ltr"><span></span><br><span>-- </span><br><span>Eric Blake, Principal Software Engineer</span><br><span>Red Hat, Inc. +1-919-301-3266</span><br><span>Virtualization: qemu.org | libvirt.org</span><br><span></span><br></div></blockquote></body></html>