61cc872456
The NBD specification defines NBD_FLAG_CAN_MULTI_CONN, which can be advertised when the server promises cache consistency between simultaneous clients (basically, rules that determine what FUA and flush from one client are able to guarantee for reads from another client). When we don't permit simultaneous clients (such as qemu-nbd without -e), the bit makes no sense; and for writable images, we probably have a lot more work before we can declare that actions from one client are cache-consistent with actions from another. But for read-only images, where flush isn't changing any data, we might as well advertise multi-conn support. What's more, advertisement of the bit makes it easier for clients to determine if 'qemu-nbd -e' was in use, where a second connection will succeed rather than hang until the first client goes away. This patch affects qemu as server in advertising the bit. We may want to consider patches to qemu as client to attempt parallel connections for higher throughput by spreading the load over those connections when a server advertises multi-conn, but for now sticking to one connection per nbd:// BDS is okay. See also: https://bugzilla.redhat.com/1708300 Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20190815185024.7010-1-eblake@redhat.com> [eblake: tweak blockdev-nbd.c to not request shared when writable, fix iotest 233] Reviewed-by: John Snow <jsnow@redhat.com> |
||
---|---|---|
.. | ||
bitmaps.rst | ||
conf.py | ||
firmware.json | ||
index.rst | ||
live-block-operations.rst | ||
nbd.txt | ||
parallels.txt | ||
pr-helper.rst | ||
prl-xml.txt | ||
qcow2.txt | ||
qed_spec.txt | ||
qemu-ga-ref.texi | ||
qemu-qmp-ref.texi | ||
qmp-intro.txt | ||
qmp-spec.txt | ||
vhost-user-gpu.rst | ||
vhost-user.json | ||
vhost-user.rst | ||
vnc-ledstate-Pseudo-encoding.txt |