doc: Permit BLOCK_STATUS reply to extend beyond request
authorEric Blake <eblake@redhat.com>
Tue, 29 May 2018 22:36:21 +0000 (17:36 -0500)
committerEric Blake <eblake@redhat.com>
Thu, 16 Aug 2018 19:23:08 +0000 (14:23 -0500)
commit6e165f59492a2040c1f2f1feb1250192ad4a546f
tree2a905f767d0475e39de93a1faca937ef52f09f6c
parent0cd9e3ba2a0f54d930d813bfde9ff9d57a12d9ed
doc: Permit BLOCK_STATUS reply to extend beyond request

When the NBD_CMD_BLOCK_STATUS extension was first discussed, the
idea of having the client's length be a hint was proposed, where
the server could reply beyond the client's request in order to
allow for fewer transactions when querying the entire disk. The
portion beyond the client's original request can only occur in
the final extent for a given context, and only if the additional
length matches the type given for the last byte actually requested
by the client.

In the meantime, qemu 2.12 was released as a first client
implementation of NBD_CMD_BLOCK_STATUS, which always sends the
NBD_CMD_FLAG_REQ_ONE flag, and which disconnects from the server
if the server's length exceeds the client request.  This was
relaxed for subsequent qemu, but it means that we have to be
explicit that a server should not send extra length except when
the client is not limiting its request to exactly one extent.

Furthermore, qemu 3.0 was recently released where the server
actually relies on this looser specification for its
qemu:dirty-bitmap:NAME context when the REQ_ONE flag is not used.

Signed-off-by: Eric Blake <eblake@redhat.com>
doc/proto.md