Re: [PATCH 2/2] doc: Add alternate trim/zero limits
On Wed, Feb 28, 2018 at 05:20:55PM -0600, 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.
This looks good.
It should probably also say that a trim size and a zeroes size SHOULD NOT be
smaller than the write size (because that makes no sense).
Maybe even MUST NOT?
> 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, 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
> + 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).
> --
> 2.14.3
>
>
--
Could you people please use IRC like normal people?!?
-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
Hacklab
Reply to: