Re: [Nbd] [Qemu-devel] [PATCH] Further tidy-up on block status
- 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...>, "Stefan stefanha@...2321... com" <stefanha@...696...>, "qemu-devel@...530..." <qemu-devel@...530...>, Pavel Borzenkov <pborzenkov@...2319...>, "Denis V . Lunev" <den@...2317...>, Markus Pargmann <mpa@...1897...>, Paolo Bonzini <pbonzini@...696...>, John Snow <jsnow@...696...>
- Subject: Re: [Nbd] [Qemu-devel] [PATCH] Further tidy-up on block status
- From: Wouter Verhelst <w@...112...>
- Date: Sat, 21 Jan 2017 13:25:50 +0100
- Message-id: <20170121122550.qzm4u7lnzj3nxsmf@...3...>
- In-reply-to: <0654e27f-9c2f-993c-befd-1f1e8e75aabf@...696...>
- References: <20161214150840.10899-1-alex@...872...> <442dcfe4-8704-2898-655e-da383a0caf76@...2319...> <220990D0-ACB6-4F25-BADF-63898FE71BED@...872...> <0654e27f-9c2f-993c-befd-1f1e8e75aabf@...696...>
On Fri, Jan 20, 2017 at 01:35:10PM -0600, Eric Blake wrote:
> On 01/20/2017 12:00 PM, Alex Bligh wrote:
> >
> >> On 20 Jan 2017, at 17:04, Vladimir Sementsov-Ogievskiy <vsementsov@...2319...> wrote:
> >>
> >> About extents: is 32bit length enough? We will have to send 4096 for empty 16tb disk..
> >
> > The nbd protocol uniformly uses 32 bit lengths (for better or for worse). This is baked into the specification heavily.
> >
> > I'm not sure sending 4,096 items for an empty 16TB disk is any great hardship to be honest.
>
> If it truly matters, an idea that has already been floated on the list
> is to add a new NBD_CMD_FLAG_SCALE (or some other spelling) that states
> that a particular command is sending lengths scaled by a particular
> factor (by the block size? obviously it would have to be better
> specified). Under this idea, the scaling factor would allow you to
> report larger extents for fewer back-and-forth operations, but it gets
> tricky if the scaling is allowed to get larger than the minimum
> granularity between extent changes.
Right, but people objected to it on grounds of it being too complicated
(which I think was a fair point).
> The other idea that has been floated is a way to report whether the
> entire export is known to be all-zero content at the time the client
> connects, which would trade 4096+ queries (you'd actually have to do
> more than 4096 queries, since length is < 4G, not <= 4G) with a single
> piece of information at the time the client connects.
That's pretty special-case, and I objected to it on those grounds :-)
However, I don't think there's anything necessarily wrong in changing
the size of the length field in the reply header of the
NBD_REPLY_TYPE_BLOCK_STATUS packet. That way, combined with the fact
that we'd already stated that a server may send more information than
was requested, a client could ask for metadata on an export, and if the
extent is the whole size of the export, the server could say so in a
single reply for all export sizes.
I suppose it'd be slightly odd to have the request use 32-bit lengths
and the response be expressed in 64-bit ones, but I suppose that's the
price we pay to remain a backwards compatible and not too complicated a
protocol.
> Either way, discussion on such enhancements are probably worth a new
> thread.
Sure.
--
< 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: