Re: [PATCH 2/2] doc: Add alternate trim/zero limits
01.03.2018 02:20, Eric Blake wrote:
The previous patch mentioned that a server that honors larger
TRIM/WRITE_ZEROES requests than accepted for WRITE has to choose
whether to advertise the maximum block size as the smaller limit
at which it does hard disconnect for WRITE, or the larger limit
at which it returns EINVAL for too-large trim/zero. Let's make
the situation less ambiguous by allowing a client and server to
negotiate explicit alternate limits for these two commands,
using the fact that NBD_OPT_GO already requires both client and
server to request additional NBD_INFO items, and to ignore items
that they don't recognize.
Signed-off-by: Eric Blake <eblake@redhat.com>
---
doc/proto.md | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/doc/proto.md b/doc/proto.md
index c607fc9..42a0a43 100644
--- a/doc/proto.md
+++ b/doc/proto.md
@@ -1249,6 +1249,54 @@ during option haggling in the fixed newstyle negotiation.
- 32 bits, preferred block size
- 32 bits, maximum block size
+ * `NBD_INFO_TRIM_SIZE` (4)
+
+ Represents alternate limits that the server will honour during
+ `NBD_CMD_TRIM`. The server SHOULD NOT send this info unless it
+ will also be advertising the transmission flag
+ `NBD_CMD_SEND_TRIM`. The minimum trim size SHOULD be a power of
+ 2,
should not it be a multiple of minimum block size from NBD_INFO_BLOCK_SIZE?
and MUST be at least as large as the preferred block size
+ advertised in `NBD_INFO_BLOCK_SIZE`; it represent the alignment
+ and minimum granularity that can be discarded (the server SHOULD
+ ignore the portion of trim requests not aligned to these
+ boundaries). The maximum trim size MUST be either 0xffffffff
+ (for no inherent 32-bit limit) or a multiple of the minimum trim
+ size, and MUST be at least as large as the maximum block size
+ advertised in `NBD_INFO_BLOCK_SIZE`. If the server does not
+ advertise alternate trim limits, then the client SHOULD limit
+ `NBD_CMD_TRIM` alignment and sizes to the same limits as any
+ other command. The *length* MUST be 10, and the reply payload
+ is interpreted as:
+
+ - 16 bits, `NBD_INFO_TRIM_SIZE`
+ - 32 bits, minimum trim size
+ - 32 bits, maximum trim size
+
+ * `NBD_INFO_ZERO_SIZE` (5)
+
+ Represents alternate limits that the server will honour during
+ `NBD_CMD_WRITE_ZEROES`. The server SHOULD NOT send this info
+ unless it will also be advertising the transmission flag
+ `NBD_CMD_SEND_WRITE_ZEROES`. The minimum zero size SHOULD be a
+ power of 2, and MUST be at least as large as the preferred block
+ size advertised in `NBD_INFO_BLOCK_SIZE`; it represents the
+ alignment and minimum granularity that can be efficiently
+ written as zeroes (a server that receives a zero request not
maybe, s/zero/write-zero/ or something like this
+ aligned to these boundaries MAY reject the request with an
+ error; or MAY perform the request using slower means such as
+ read-modify-write). The maximum zero size MUST be either
+ 0xffffffff (for no inherent 32-bit limit) or a multiple of the
+ minimum zero size, and MUST be at least as large as the maximum
+ block size advertised in `NBD_INFO_BLOCK_SIZE`. If the server
+ does not advertise alternate zero limits, then the client SHOULD
+ limit `NBD_CMD_WRITE_ZEROES` alignment and sizes to the same
+ limits as any other command. The *length* MUST be 10, and the
+ reply payload is interpreted as:
+
+ - 16 bits, `NBD_INFO_ZERO_SIZE`
+ - 32 bits, minimum zero size
+ - 32 bits, maximum zero size
+
* `NBD_REP_META_CONTEXT` (4)
Defined by the experimental `BLOCK_STATUS` [extension](https://github.com/NetworkBlockDevice/nbd/blob/extension-blockstatus/doc/proto.md).
--
Best regards,
Vladimir
Reply to: