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

Re: [PATCH] doc/proto: drop max-block restriction for data-less commands



Thanks, applied.

On Tue, Feb 04, 2020 at 03:02:57PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> max-block restriction make sense for NBD_CMD_WRITE and NBD_CMD_READ to
> avoid big data transfer and long io operations at server side.
> NBD_CMD_WRITE_ZEROES still may be realized on server through direct
> writing zeroes, which may lead to long operation and huge allocation
> and should be restricted by max-block.
> Same for NBD_CMD_CACHE: long operation / big allocation.
> 
> Still, NBD_CMD_TRIM, NBD_CMD_BLOCK_STATUS and NBD_CMD_WRITE_ZEROES with
> NBD_CMD_FLAG_FAST_ZERO set are over-restricted by it. So, for better
> performance, drop these restrictions.
> 
> Note, that Qemu nbd server already works accordingly to this patch: it
> doesn't check the restriction for NBD_CMD_TRIM, NBD_CMD_BLOCK_STATUS
> and NBD_CMD_WRITE_ZEROES.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> ---
> 
> RFC question: hmm, Qemu nbd doesn't check restriction for WRITE_ZEROES
> at all, even without NBD_CMD_FLAG_FAST_ZERO flag.
> 
> So, we probably could go further, and allow big WRITE_ZEROES without
> this flag..
> 
> Or may be change s/MUST NOT/SHOULD NOT/ for this case..
> 
> 
>  doc/proto.md | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/doc/proto.md b/doc/proto.md
> index fc7baf6..4b067f5 100644
> --- a/doc/proto.md
> +++ b/doc/proto.md
> @@ -815,9 +815,12 @@ Where a transmission request can have a nonzero *offset* and/or
>  the client MUST ensure that *offset* and *length* are integer
>  multiples of any advertised minimum block size, and SHOULD use integer
>  multiples of any advertised preferred block size where possible.  For
> -those requests, the client MUST NOT use a *length* larger than any
> -advertised maximum block size or which, when added to *offset*, would
> -exceed the export size.  The server SHOULD report an `NBD_EINVAL` error if
> +those requests, the client MUST NOT use a *length* which, when added to
> +*offset*, would exceed the export size. Also for NBD_CMD_READ,
> +NBD_CMD_WRITE, NBD_CMD_CACHE and NBD_CMD_WRITE_ZEROES (except for
> +when NBD_CMD_FLAG_FAST_ZERO is set), the client MUST NOT use a *length*
> +larger than any advertised maximum block size.
> +The server SHOULD report an `NBD_EINVAL` error if
>  the client's request is not aligned to advertised minimum block size
>  boundaries, or is larger than the advertised maximum block size.
>  Notwithstanding any maximum block size advertised, either the server
> -- 
> 2.21.0
> 
> 

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard


Reply to: