On 18 Apr 2016, at 15:53, Eric Blake <eblake@...696...> wrote: > 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" We did, but we didn't actually say *how* this was done. The text is: > A server that wants to enforce block sizes other than the defaults specified here MAY refuse to go into transmission phase with a client that uses NBD_OPT_EXPORT_NAME or failed to use NBD_OPT_BLOCK_SIZE, This is somewhat confusing as it sounds like it's saying 'drop the connection' with NBD_OPT_EXPORT_NAME, but then comes the 'or' bit. It's possible (if ugly) to use NBD_OPT_BLOCK_SIZE then NBD_OPT_EXPORT_NAME. I think this probably means "A server that wants to enforce block sizes other than the defaults specified here MAY refuse to go into transmission phase with a client failed to use NBD_OPT_BLOCK_SIZE, in which case it MAY initiate a hard disconnect if NBD_OPT_EXPORT_NAME is received or error NBD_OPT_GO with XXXX" I'm asking what XXXX should be (there must be some value else it will be impossible to avoid going into transmission phase), and also saying presumably it can error NBD_OPT_INFO similarly. > >> 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. The problem is if it does Write1 -> happens to succeed Write2 -> fails And the image is corrupt if write1 succeeded but write2 failed. > 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. Yep. >> 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? Yes please! -- Alex Bligh
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail