Re: [Nbd] [PATCH v4] doc: Add NBD_CMD_BLOCK_STATUS extension
- To: Eric Blake <eblake@...696...>
- Cc: "nbd-general@lists.sourceforge.net" <nbd-general@lists.sourceforge.net>, Kevin Wolf <kwolf@...696...>, Vladimir Sementsov-Ogievskiy <vsementsov@...2319...>, "qemu-devel@...530..." <qemu-devel@...530...>, Pavel Borzenkov <pborzenkov@...2319...>, "Stefan stefanha@...2321... com" <stefanha@...696...>, "Denis V. Lunev" <den@...2317...>, Markus Pargmann <mpa@...1897...>, Paolo Bonzini <pbonzini@...696...>, John Snow <jsnow@...696...>
- Subject: Re: [Nbd] [PATCH v4] doc: Add NBD_CMD_BLOCK_STATUS extension
- From: Wouter Verhelst <w@...112...>
- Date: Mon, 12 Dec 2016 21:49:13 +0100
- Message-id: <20161212204913.oaatvexhnndyhhwa@...3...>
- In-reply-to: <20161212202615.llsqhojp2xztfao3@...3...>
- References: <20161212182119.dceppkzqb7gftsl5@...3...> <bbdb71c7-540e-f5d9-c779-adddf4a0c79c@...696...> <20161212202615.llsqhojp2xztfao3@...3...>
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
Reply to: