Re: [Qemu-devel] [Nbd] [PATCH v4] doc: Add NBD_CMD_BLOCK_STATUS extension

[Wouter Verhelst]

On Mon, Dec 12, 2016 at 09:26:15PM +0100, Wouter Verhelst wrote:
> > Do we still want to require servers to always send 16 extents (when not
> > limited to exactly 1), or is it better to just state that as long as the
> > server sends at least one extent (so that the client can make progress),
> > then the server can shorten the reply if it is resource-intensive to
> > provide details over the entire client request?
> 
> Hrm, I wanted to drop that (I did drop another reference to that thing,
> I though), but apparently I forgot.

...and I still did. I don't think it's worth sending another full diff
from extension-structured-reply for that, but here's the diff from v5:

diff --git a/doc/proto.md b/doc/proto.md
index 526f71a..1d6db4b 100644
--- a/doc/proto.md
+++ b/doc/proto.md
@@ -1242,9 +1242,11 @@ interpret the "length" bytes of payload.
     Even if the client did not use the `NBD_CMD_FLAG_REQ_ONE` flag in
     its request, the server MAY return less descriptors in the reply
     than would be required to fully specify the whole range of requested
-    information to the client, if the number of descriptors would be
-    over 16 otherwise and looking up the information would be too
-    resource-intensive for the server.
+    information to the client, if looking up the information would be
+    too resource-intensive for the server, so long as at least one
+    extent is returned. Servers should however be aware that most
+    clients implementations will then simply ask for the next extent
+    instead.

Regards,

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12