[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Nbd] [PATCH v5 2/2] doc: Add details on block sizes



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
does advertise a block size, is the server within its rights
to refuse to go into transmission mode with a client? 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".

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.

-- 
Alex Bligh







Reply to: