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
> >> <vsement...@virtuozzo.com> 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
