So,
On Tue, Apr 26, 2016 at 08:36:10PM +0100, Alex Bligh wrote:
> Allow a client to requests specific bits of information using
> NBD_OPT_INFO and thereby signal to the server that it supports them.
> This makes it easier for the server to know whether the information
> it is providing will be used / respected.
>
> Now a server can determine whether a client supports block sizes by
> the fact it uses NBD_OPT_INFO or NBD_OPT_GO with an NBD_INFO_BLOCK_SIZE,
> request as these are part of the same extension, so there is no
> need for NBD_OPT_BLOCK_SIZE.
I think we're close, except for this:
- I'd like to change things so that NBD_OPT_INFO doesn't commit a client
to following block sizes. The rationale for this is bifold:
- First and foremost, it will simplify the server, since it doesn't
need to retain as much state (it can simply look at the NBD_OPT_GO
command, and that one alone, to decide on whether it can do the
optimized O_DIRECT path, rather than having to do a lot of global
variables and ifs and buts etc).
- Second (and somewhat less likely), it allows a client to see if a
server allows for a block size that it too can support without
having to disconnect and reconnect to get more information. Let's
say a client exists which can support the default block size and
which can group and split requests if needs be, but which cannot
guarantee a minimum block size other than 512. Such a client might
want to check what the maximum block size is, but if the server
replies to that with "Oh jolly, I can go to my optimized path now!
Please use a minimum and preferred block size of 4K", it's pretty
much screwed. As said, this is somewhat less likely to happen, but
if we can support it, and in combination with the above, I think we
should do this.
- I think we should not allow a client to do OPT_INFO followed by
OPT_EXPORT_NAME. The latter is broken, and a client which can do
OPT_INFO can very much do OPT_GO too. This should be a MUST for the
client, and a SHOULD for the server to do a hard disconnect then. That
also makes it easier to implement the above (and is possibly related)
Other than that, LGTM.
--
< 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
Attachment:
signature.asc
Description: PGP signature