Re: [Qemu-devel] [PATCH] Further tidy-up on block status

From: Eric Blake <eblake@redhat.com>
To: Alex Bligh <alex@alex.org.uk>,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: "nbd-general@lists.sourceforge.net"
	<nbd-general@lists.sourceforge.net>,
	Kevin Wolf <kwolf@redhat.com>, "Denis V . Lunev" <den@openvz.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Pavel Borzenkov <pborzenkov@virtuozzo.com>,
	"Stefan stefanha@redhat. com" <stefanha@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Markus Pargmann <mpa@pengutronix.de>, Wouter Verhelst <w@uter.be>,
	John Snow <jsnow@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] Further tidy-up on block status
Date: Fri, 20 Jan 2017 13:35:10 -0600	[thread overview]
Message-ID: <0654e27f-9c2f-993c-befd-1f1e8e75aabf@redhat.com> (raw)
In-Reply-To: <220990D0-ACB6-4F25-BADF-63898FE71BED@alex.org.uk>

[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]

On 01/20/2017 12:00 PM, Alex Bligh wrote:
> 
>> On 20 Jan 2017, at 17:04, Vladimir Sementsov-Ogievskiy <vsementsov@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.

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.

Either way, discussion on such enhancements are probably worth a new thread.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]