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

Re: [PATCH v3 2/5] doc: Fix requirement on preferred size



On Wed, Mar 28, 2018 at 02:43:27PM -0500, Eric Blake wrote:
> Setting the preferred size to >= min(min_size, 4k) doesn't make
> sense (a preferred size of 4k when min_size is 64k means that
> you get efficient I/O when requesting something smaller than
> the minimum granularity?).  Fix it by documenting the intended
> semantics that the preferred size is >= max(min_size, 4k).

Thanks, that does seem like an improvement.

Side note: there are still hard disks out there which use 512-byte
blocks[1]. It would make sense for an nbd server exporting a raw hard
disk with 512-byte blocks to use that as the preferred size.

What was the reasoning we used originally for clamping that to 4k at
minimum?

[1] The dedicated server that I have at a hoster started out with a
bunch of 1.5TiB disks that did.

> Reported-by: Vladimer Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> Signed-off-by: Eric Blake <eblake@redhat.com>
> ---
>  doc/proto.md | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/doc/proto.md b/doc/proto.md
> index adf2651..48a4ef5 100644
> --- a/doc/proto.md
> +++ b/doc/proto.md
> @@ -776,7 +776,7 @@ client would be unable to access the final few bytes of the export.
>  The preferred block size represents the minimum size at which aligned
>  requests will have efficient I/O, avoiding behaviour such as
>  read-modify-write.  If advertised, this MUST be a power of 2 at least
> -as large as the smaller of the minimum block size and 2^12 (4,096),
> +as large as the maximum of the minimum block size and 2^12 (4,096),
>  although larger values (such as the minimum granularity of a hole) are
>  also appropriate.  The preferred block size MAY be larger than the
>  export size, in which case the client is unable to utilize the
> -- 
> 2.14.3
> 
> 

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
     Hacklab


Reply to: