Re: [RFC PATCH] spec: Relax block status alignment to match existing servers
Hi Eric,
On Sat, May 31, 2025 at 10:38:42AM -0500, Eric Blake wrote:
> At least nbdkit 1.42 has several scenarios where it can advertise a
> minimum block size, but where block status results are not aligned to
> that size. While most of those instances are bugs fixed in the
> upcoming 1.44, we have to consider the case when a server advertises
> an image size which is not a multiple of the minimum block size. The
> spec is already clear that a server SHOULD advertise aligned sizes,
> but when it doesn't, the requirement that block status results be
> aligned is impossible to meet. Relaxing the standard from MUST to
> SHOULD warns clients to be prepared for weaknesses in the server, as
> well as making it less troublesome to try and collect block status
> even for an unaligned tail of an image.
>
> Signed-off-by: Eric Blake <eblake@redhat.com>
> ---
>
> I'm not sure if I want to apply this patch as-is, or if we should come
> up with a better wording.
Yeah, I don't think I can come up with anything better, either. Please
apply.
> Of note: we already use SHOULD and not MUST
> on structured replies to NBD_CMD_READ splitting a response into
> multiple chunks when reading holes is encountered. The biggest reason
> for this patch is to inform clients that not all servers are always
> compliant (in particular, nbdkit 1.42 has several issues, and while
> I'm patching most of them for 1.44, nbdkit still takes the approach
> that it has no problem with a plugin advertising unaligned sizes, at
> which point an unaligned block status request and response are the
> only way to learn about that unaligned tail).
>
> doc/proto.md | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/doc/proto.md b/doc/proto.md
> index 565fbebc..b403bae1 100644
> --- a/doc/proto.md
> +++ b/doc/proto.md
> @@ -2267,8 +2267,10 @@ The following request types exist:
> places for an exception), in part to avoid an amplification effect
> where a series of smaller descriptors can cause the server's reply
> to occupy more bytes than the *length* of the client's request.
> - The server MUST use descriptor lengths that are an integer
> - multiple of any advertised minimum block size. The status flags
> + The server SHOULD use descriptor lengths that are an integer
> + multiple of any advertised minimum block size, with an obvious
> + exception at the end of the image if the image size itself is
> + unaligned. The status flags
> are intentionally defined so that a server MAY always safely
> report a status of 0 for any block, although the server SHOULD
> return additional status values when they can be easily detected.
> --
> 2.49.0
>
>
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Reply to: