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

[Wouter Verhelst <w@...112...>]

On Thu, Apr 28, 2016 at 06:07:36PM +0100, Alex Bligh wrote:
> On 28 Apr 2016, at 17:54, Wouter Verhelst <w@...112...> wrote:
> > [...]
> >> +      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?
> 
> No I think that one is right.
> 
> You can't send NBD_REP_ERR_BLOCK_SIZE_REQD in response to an NBD_OPT_INFO
> if it's asked for NBD_INFO_BLOCK_SIZE.
> 
> If it has not asked for NBD_INFO_BLOCK_SIZE it is legitimate to error
> the NBD_OPT_INFO with NBD_REP_ERR_BLOCK_SIZE_REQD so that the client knows
> that if sends an NBD_OPT_GO with the same parameters it would get that
> error, and hence it should either ask for block size constraints or
> give up.

Oh, right. I hadn't considered sending an ERR_BLOCK_SIZE_REQD on an INFO
request without a request for block sizes (after all, it's just an
information request, the fact that you don't need information on
everything doesn't mean you'll break things), but I suppose it makes
sense to do that.

It might make sense for such a server to still send all the information
that the client *did* ask for in the reply, it would just send an error
along as well to signal that more is going to be needed, but I don't
suppose that's critical.

> I'm going to apply v6 with your and Eric's changes (plus or minus
> a couple of tiny grammar nits).

Fair enough.

-- 
< 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