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

From: Wouter Verhelst <w@uter.be>
To: Eric Blake <eblake@redhat.com>
Cc: Alex Bligh <alex@alex.org.uk>, nbd list <nbd@other.debian.org>,
	Kevin Wolf <kwolf@redhat.com>,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	qemu-devel@nongnu.org, stefanha@redhat.com,
	Paolo Bonzini <pbonzini@redhat.com>,
	"Denis V . Lunev" <den@openvz.org>, John Snow <jsnow@redhat.com>
Subject: Re: [Qemu-devel] [Nbd] [PATCH] Further tidy-up on block status
Date: Fri, 4 May 2018 08:40:05 +0200	[thread overview]
Message-ID: <20180504064005.GB7456@grep.be> (raw)
In-Reply-To: <facb7ba3-edd3-45f9-ca6f-68ac7d5005c9@redhat.com>

On Thu, May 03, 2018 at 12:26:36PM -0500, Eric Blake wrote:
> [resend with updated list address and pruning addresses that bounced]
> 
> Reviving this discussion, as it still seems useful to incorporate now that
> BLOCK_STATUS is only recently part of the standard.

Yeah. I thought we'd incorporated it already at the time, but apparently
not.

I still think this is a good idea, and that we should do it.

> On 12/14/2016 11:09 AM, Wouter Verhelst wrote:
> 
> > One thing I've been thinking about that we might want to add:
> > 
> > There may be cases where a server, in performing the required calls to
> > be able to handle a BLOCK_STATUS request, will end up with more
> > information than the client asked; e.g., if the client asked information
> > in the base:allocation context on an extent at offset X of length Y,
> > then the server might conceivably do an lseek(SEEK_DATA) and/or
> > lseek(SEEK_HOLE). The result of that call might be that the file offset
> > will now point to a location Z, where Z > (X+Y).
> > 
> > Currently, our spec says "the sum of the *length* fields MUST not be
> > greater than the overall *length* of request". This means that in
> > essense, the server then has to throw away the information it has on the
> > range Z - (X + Y). In case a client was interested in that information,
> > that seems like a waste. I would therefore like to remove that
> > requirement, by rephrasing that "sum of the *length* fields" thing into
> > something along the following lines:
> > 
> >    In case the server returns N extents, the sum of the *length* fields
> >    of the first N-1 extents MUST NOT be greater than the overall *length*
> >    of the request. The final extent MAY exceed the length of the request
> >    if the server has that information anyway as a side effect of looking
> >    up the required information and wishes to share it.
> > 
> > This would then result in the fact that the "length" field in the
> > BLOCK_STATUS command would be little more than a hint, since we're
> > saying that a server can return more data than requested (if it's
> > available anyway) and less data than requested (if it would be too
> > resource-intensive to provide all the information). Not sure whether all
> > that makes much sense anymore, but hey.
> > 
> > In addition, the combination of a server providing more information than
> > requested with a "REQ_ONE" flag and a length field of zero could be an
> > interesting way to enumerate a whole export, too. Essentially, we could
> > define that as a client saying "I'm interested in what the size of the
> > extent at offset X is, and what its properties are".
> > 
> > Thoughts?
> > 
> 
> -- 
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.           +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
> 

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
     Hacklab