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

[RFC PATCH] spec: Relax block status alignment to match existing servers



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.  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


Reply to: