Re: [Nbd] [PATCH v2] doc: Add new NBD_REP_INFO reply, for advertising block size

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

Eric,

On Tue, Apr 12, 2016 at 06:16:54PM -0600, Eric Blake wrote:
> Existing NBD servers often have limitations, such as requiring
> actions to be aligned to block sizes or limiting maximum
> transactions to avoid denial of service attacks; for example,
> qemu's NBD server refuses any transaction larger than 32M.  But
> to date, clients have to learn these limitations via out-of-band
> means.
> 
> This alters NBD_OPT_INFO and NBD_OPT_GO to use a new reply type
> NBD_REP_INFO (rather than overloading NBD_REP_SERVER), so that
> we have a future-proof way of supplying as much additional
> structured information about an export as we want.
> 
> Design decision: a client that wants to learn block sizes MUST
> use NBD_OPT_GO, rather than the old NBD_OPT_EXPORT_NAME, even
> though we could have repurposed some of the reserved zeroes when
> NBD_FLAG_C_NO_ZEROES is not in effect, because we don't want to
> encourage any further abuse of NBD_OPT_EXPORT_NAME.
> 
> Design decision: no new global NBD_FLAG or NBD_OPT are required;
> there is nothing for the client to negotiate.  The server merely
> provides as much information as it can, and the client then
> interprets what information it understands.  The items are
> structured so that a client can ignore details from the server
> that the client does not know about, and that we can easily add
> future items of information.

General note (in-depth review may follow later):

Currently, there are no default minimum or maximum block sizes, and
therefore they are effectively limited to "1 byte" for the minimum block
size, and "the size of the device" for the maximum block size.

I do agree that it might be advantageous for the server to announce such
minimum and maximum sizes, but I don't think that defining defaults that
differ from what historically has been the effective default is the
right way to go.

Therefore, I would like this to say that unless you announce
differently, the maximum block size is the size of the device, and the
minimum block size is 1 byte.

Having a default for preferred block size sounds sane, although it might
be better to switch it to 4096 (which is what most conversations seem to
use today) rather than 512.

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