[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Nbd] [PATCHv6] Remove NBD_OPT_BLOCK_SIZE; add specific requests to NBD_OPT_INFO



On Thu, Apr 28, 2016 at 09:58:52AM +0100, Alex Bligh wrote:
[...]
> +Some servers are able to make optimizations, such as opening files
> +with O_DIRECT, if they know that the client will obey a particular
> +minimum block size, where it must fall back to safer but slower code
> +if the client might send unaligned requests. A server is entitled to
> +assume that a client that issues `NBD_OPT_GO` including an
> +`NBD_INFO_BLOCK_SIZE` information request, will either support the block
> +size constraints it has supplied using `NBD_INFO_BLOCK_SIZE`, or will not
> +continue the session. The client's use of `NBD_INFO_BLOCK_SIZE` in an
> +`NBD_OPT_INFO` does not of itself entitle the server to make this
> +assumption.

I think this paragraph will read easier if it's worded in terms of "a
client MUST" rather than "a server may assume"; something along the
following lines:

(...) if the client might send unaligned requests. For that reason, if a
client issues `NBD_OPT_GO` including an `NBD_INFO_BLOCK_SIZE`
information request, it MUST abide by the block size constraints it
receives. Clients MAY issue `NBD_OPT_INFO` with `NBD_INFO_BLOCK_SIZE` to
learn the server's constraints without committing to them.

That's even shorter, too.

[...]
> @@ -823,6 +842,9 @@ of the newstyle negotiation.
>      A major problem of this option is that it does not support the
>      return of error messages to the client in case of problems. To
>      remedy this, `NBD_OPT_GO` has been introduced (see below).
> +    A client thus SHOULD use `NBD_OPT_GO` in preference to
> +    `NBD_OPT_EXPORT_NAME` but MUST fall back to `NBD_OPT_EXPORT_NAME`
> +    if `NBD_OPT_GO` is not supported.

I don't think we should write backcompat stuff as a MUST. This can be a
SHOULD, or even a MAY.

[...]
> +      request block size constraints using `NBD_INFO_BLOCK_SIZE` prior
> +      to entering transmission phase, because the server will be using
> +      non-default block sizes constraints. The server MUST NOT send this
> +      error if block size constraints were requested with
> +      `NBD_INFO_BLOCK_SIZE` with the `NBD_OPT_INFO` or `NBD_OPT_GO`

only NBD_OPT_GO here?

> +      request. The server SHOULD NOT send this error if it is using
> +      default block size constraints or block size constraints
> +      negotiated out of band.
-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12



Reply to: