diff options
| author | Eric Blake <eblake@redhat.com> | 2022-05-11 19:49:24 -0500 |
|---|---|---|
| committer | Kevin Wolf <kwolf@redhat.com> | 2022-05-12 13:10:52 +0200 |
| commit | 58a6fdcc9efb2a7c1ef4893dca4aa5e8020ca3dc (patch) | |
| tree | 2dba1567609a2df70bbb9e01e2fb89b18b2238ee /qapi | |
| parent | a5fced40212ed73c715ca298a2929dd4d99c9999 (diff) | |
| download | qemu-58a6fdcc9efb2a7c1ef4893dca4aa5e8020ca3dc.zip qemu-58a6fdcc9efb2a7c1ef4893dca4aa5e8020ca3dc.tar.gz qemu-58a6fdcc9efb2a7c1ef4893dca4aa5e8020ca3dc.tar.bz2 | |
nbd/server: Allow MULTI_CONN for shared writable exports
According to the NBD spec, a server that advertises
NBD_FLAG_CAN_MULTI_CONN promises that multiple client connections will
not see any cache inconsistencies: when properly separated by a single
flush, actions performed by one client will be visible to another
client, regardless of which client did the flush.
We always satisfy these conditions in qemu - even when we support
multiple clients, ALL clients go through a single point of reference
into the block layer, with no local caching. The effect of one client
is instantly visible to the next client. Even if our backend were a
network device, we argue that any multi-path caching effects that
would cause inconsistencies in back-to-back actions not seeing the
effect of previous actions would be a bug in that backend, and not the
fault of caching in qemu. As such, it is safe to unconditionally
advertise CAN_MULTI_CONN for any qemu NBD server situation that
supports parallel clients.
Note, however, that we don't want to advertise CAN_MULTI_CONN when we
know that a second client cannot connect (for historical reasons,
qemu-nbd defaults to a single connection while nbd-server-add and QMP
commands default to unlimited connections; but we already have
existing means to let either style of NBD server creation alter those
defaults). This is visible by no longer advertising MULTI_CONN for
'qemu-nbd -r' without -e, as in the iotest nbd-qemu-allocation.
The harder part of this patch is setting up an iotest to demonstrate
behavior of multiple NBD clients to a single server. It might be
possible with parallel qemu-io processes, but I found it easier to do
in python with the help of libnbd, and help from Nir and Vladimir in
writing the test.
Signed-off-by: Eric Blake <eblake@redhat.com>
Suggested-by: Nir Soffer <nsoffer@redhat.com>
Suggested-by: Vladimir Sementsov-Ogievskiy <v.sementsov-og@mail.ru>
Message-Id: <20220512004924.417153-3-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to 'qapi')
| -rw-r--r-- | qapi/block-export.json | 8 |
1 files changed, 6 insertions, 2 deletions
diff --git a/qapi/block-export.json b/qapi/block-export.json index 1de16d2..7776248 100644 --- a/qapi/block-export.json +++ b/qapi/block-export.json @@ -22,7 +22,9 @@ # recreated on the fly while the NBD server is active. # If missing, it will default to denying access (since 4.0). # @max-connections: The maximum number of connections to allow at the same -# time, 0 for unlimited. (since 5.2; default: 0) +# time, 0 for unlimited. Setting this to 1 also stops +# the server from advertising multiple client support +# (since 5.2; default: 0) # # Since: 4.2 ## @@ -51,7 +53,9 @@ # recreated on the fly while the NBD server is active. # If missing, it will default to denying access (since 4.0). # @max-connections: The maximum number of connections to allow at the same -# time, 0 for unlimited. (since 5.2; default: 0) +# time, 0 for unlimited. Setting this to 1 also stops +# the server from advertising multiple client support +# (since 5.2; default: 0). # # Returns: error if the server is already running. # |