Re: [Nbd] [PATCH v4 2/2] doc: Add details on block sizes

[Alex Bligh <alex@...872...>]

On 15 Apr 2016, at 04:09, Eric Blake <eblake@...696...> wrote:

> +## Block sizes
> +
> +During transmission phase, several operations are constrained by the
> +export size sent by the final `NBD_OPT_EXPORT_NAME` or `NBD_OPT_GO`,
> +as well as by three block sizes defined here (minimum, preferred, and
> +maximum).  During the handshake phase, a client MAY announce its
> +intention to honor server block sizes via the experimental
> +`BLOCK_SIZE` extension; see below.

"If a client can honor server block sizes (as set out in the
experimental `BLOCK_SIZE` extension) it SHOULD announce this
during the handshake phase"

>  A client that is worried about
> +block size constraints SHOULD use `NBD_OPT_GO` rather than
> +`NBD_OPT_EXPORT_NAME`.

"Such a client SHOULD use"...

>  A server SHOULD advertise the block size
> +contraints during handshake phase via the experimental `INFO`
> +extension; see below.  A server and client MAY agree on block sizes
> +via out of band means.
> +
> +If block sizes have not been advertised or agreed on externally, then
> +a client SHOULD assume a default minimum block size of 1, a preferred
> +block size of 4,096, and no inherent maximum block size.  A server
> +that wants to enforce block sizes other than the defaults specified
> +here MUST support the experimental `INFO` extension, and MAY refuse to
> +go into transmission phase for a client that uses

s/for/with/

> +The maximum block size represents the maximum length that the server
> +is willing to handle in one request.  If advertised, it MUST be either
> +an integer multiple of the minimum block size or the value
> +4,294,967,295 (that is, (uint32_t)-1) for no inherent limit, MUST be
> +at least as large as the preferred block size, and SHOULD be at least
> +3,355,442 (32M),

That looks more like 3MB to me?

otherwise LGTM

-- 
Alex Bligh