On 1/5/19 8:50 AM, Richard W.M. Jones wrote:
This allows multiple connections from a single client, and should be
safe assuming flush/FUA has been implemented correctly in the previous
commit.
Looks safe to me between the two patches. The NBD spec also states:
* A client which uses multiple connections to a server to parallelize
commands MUST NOT issue an `NBD_CMD_FLUSH` request until it has
received the reply for all write commands which it expects to be
covered by the flush.
which implies that even if we encounter this race:
client A: client B:
issue write
issue flush
flush completes
write completes
we don't have to worry about that case, because client B didn't wait for
the response before client A requested the flush. Kernel fdatasync()
semantics match what we want (all writes that any client has received a
reply to will be included in the flush, even if the flush is on a
different client).
ACK
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org