On 04/28/2016 02:58 AM, 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. > > Signed-off-by: Alex Bligh <alex@...872...> > --- > doc/proto.md | 140 ++++++++++++++++++++++++++++++++++------------------------- > 1 file changed, 80 insertions(+), 60 deletions(-) > +++ b/doc/proto.md > @@ -636,34 +636,53 @@ This functionality has not yet been implemented by the reference > implementation, but was implemented by qemu and subsequently > by other users, so has been moved out of the "experimental" section. > > -## Block sizes > +## Block size constraints > > During transmission phase, several operations are constrained by the > export size sent by the final `NBD_OPT_EXPORT_NAME` or `NBD_OPT_GO`, > -as well as by three block sizes defined here (minimum, preferred, and > -maximum). If a client can honor server block sizes (as set out in My fault for introducing it... > -`NBD_OPT_BLOCK_SIZE`), it SHOULD announce this > -during the handshake phase, and SHOULD use `NBD_OPT_GO` rather than > -`NBD_OPT_EXPORT_NAME`. A server SHOULD advertise the block size > -contraints during handshake phase via `NBD_OPT_INFO`. A server > -and client MAY agree on block sizes via out of band means. > - > -If block sizes have not been advertised or agreed on externally, then > -a client SHOULD assume a default minimum block size of 1, a preferred > +as well as by three block size constraints defined here (minimum, > +preferred, and maximum). > + > +If a client can honor server block size constraints (as set out below ...but while you are touching this, s/honor/honour/ so that the document consistently uses UK spellings. > @@ -1077,13 +1093,17 @@ during option haggling in the fixed newstyle negotiation. > > * `NBD_INFO_BLOCK_SIZE` (3) > > - Represents the server's advertised block sizes; see the "Block > - sizes" section for more details on what these values represent, > - and on constraints on their values. The server MAY send this > - info whether or not the client has negotiated > - `NBD_OPT_BLOCK_SIZE`, and SHOULD send this info if it intends to > - enforce block sizes other than the defaults. The *length* MUST > - be 14, and the reply payload is interpreted as: > + Represents the server's advertised block size constraints; see the > + "Block size constraints" section for more details on what these > + values represent, and on constraints on their values. The server > + MUST send this info if it is requested and it intends to enforce > + block size constraints other than the defaults. After > + sending this information in response to an `NBD_OPT_GO`, s/`NBD_OPT_GO`/`NBD_OPT_GO` where the client requested `NBD_INFO_BLOCK_SIZE`/ > the server > + can legitimately assume that any client that continues the session > + will support the block size constraints supplied (note that this > + assumption cannot be made solely on the basis of an `NBD_OPT_INFO` > + with an `NBD_INFO_BLOCK_SIZE` request). s/request)/request, nor if the client did not request `NBD_INFO_BLOCK_SIZE`)/ > The *length* MUST be 14, > + and the reply payload is interpreted as: > > - 16 bits, `NBD_INFO_BLOCK_SIZE` > - 32 bits, minimum block size > Otherwise I think this is ready. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature