Re: [Nbd] [PATCHv6] Remove NBD_OPT_BLOCK_SIZE; add specific requests to NBD_OPT_INFO
- To: Alex Bligh <alex@...872...>
- Cc: "nbd-general@lists.sourceforge.net" <nbd-general@lists.sourceforge.net>
- Subject: Re: [Nbd] [PATCHv6] Remove NBD_OPT_BLOCK_SIZE; add specific requests to NBD_OPT_INFO
- From: Wouter Verhelst <w@...112...>
- Date: Thu, 28 Apr 2016 18:54:09 +0200
- Message-id: <20160428165409.GC3082@...3...>
- In-reply-to: <1461833932-44607-1-git-send-email-alex@...872...>
- References: <1461833932-44607-1-git-send-email-alex@...872...>
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: