On 04/17/2016 08:34 AM, Alex Bligh wrote: > > On 16 Apr 2016, at 22:31, Eric Blake <eblake@...696...> wrote: > >> +## Block sizes >> + >> +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 the >> +experimental `BLOCK_SIZE` extension below), 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 the experimental `INFO` >> +extension; see below. 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 >> +block size of 2^12 (4,096), and a maximum block size of the smaller of >> +the export size or 0xffffffff (effectively unlimited). A server that >> +wants to enforce block sizes other than the defaults specified here >> +MUST support the experimental `INFO` extension, and MAY refuse to go >> +into transmission phase with a client that uses `NBD_OPT_EXPORT_NAME` >> +or failed to use `NBD_OPT_BLOCK_SIZE`, although a server SHOULD permit >> +such clients if block sizes can be agreed on externally. When >> +allowing such clients, the server MUST cleanly error commands that >> +fall outside block size parameters without corrupting data; even so, >> +this may limit interoperability. > > I know I've now merged this and put it in a separate branch, but > implementing it gave me a thought. > > If a client does NOT send NBD_OPT_BLOCKSIZE, and the server NBD_OPT_BLOCK_SIZE > does advertise a block size, is the server within its rights > to refuse to go into transmission mode with a client? We DID say "MAY refuse to go into transmission phase" > Something > along the lines of "If you connected then you'd only break > things, as I'll error the first unaligned write, by which > time the disk will be corrupt". The server isn't the one corrupting the image. Any client that fails to check for write errors deserves the corruption it gets for continuing to operate as if all writes had succeeded. But you ARE right that it may be worth an additional error code to explicitly state that "I'm unwilling to go into transmission phase until you prove to me you know about my non-default block sizes" as a result to NBD_OPT_GO (for NBD_OPT_EXPORT_NAME, the best you can do is terminate the connection, without stating why); and that the same error for NBD_OPT_INFO is a nice hint of what is needed to further make use of the export. > > I think a server should be able to error NBD_OPT_GO with an > error under such circumstances (basically "send me something > that tells me you know about block sizes"), in which case > we'll need an error code for that, and we'll need > NBD_OPT_INFO to be able to return that error code too. > > I can't immediately see an appropriate linux error number. Linux error numbers don't matter during handshake phase (only for transmission phase). Just use the next available number in NBD_REP_ERR_ namespace. Would you like me to write up the doc patch? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature