From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:50649)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pborzenkov@virtuozzo.com>) id 1aoByV-0005C7-Ri
	for qemu-devel@nongnu.org; Thu, 07 Apr 2016 11:36:04 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pborzenkov@virtuozzo.com>) id 1aoByQ-0005bk-Sb
	for qemu-devel@nongnu.org; Thu, 07 Apr 2016 11:36:03 -0400
Received: from mail-db3on0125.outbound.protection.outlook.com
	([157.55.234.125]:38028
	helo=emea01-db3-obe.outbound.protection.outlook.com)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pborzenkov@virtuozzo.com>) id 1aoByQ-0005bR-8S
	for qemu-devel@nongnu.org; Thu, 07 Apr 2016 11:35:58 -0400
Date: Thu, 7 Apr 2016 18:35:49 +0300
From: Pavel Borzenkov <pborzenkov@virtuozzo.com>
Message-ID: <20160407153549.GA11233@phobos>
References: <1459787950-15286-1-git-send-email-eblake@redhat.com>
	<20160405040527.GA4183@noname.redhat.com>
	<5703C0EC.6080306@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5703C0EC.6080306@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, nbd-general@lists.sourceforge.net, qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>, "Denis V.
	Lunev" <den@openvz.org>, Wouter Verhelst <w@uter.be>

On Tue, Apr 05, 2016 at 03:43:08PM +0200, Paolo Bonzini wrote:
> 
> 
> On 05/04/2016 06:05, Kevin Wolf wrote:
> > The options I can think of is adding a request field "max number of
> > descriptors" or a flag "only single descriptor" (with the assumption
> > that clients always want one or unlimited), but maybe you have a better
> > idea.
> 
> I think a limit is better.  Even if the client is ultimately going to
> process the whole file, it may take a very long time and space to
> retrieve all the descriptors in one go.  Rather than query e.g. 16GB at
> a time, I think it's simpler to put a limit of 1024 descriptors or so.

Agree. I'm not sure that the value of the limit should be hard-coded
into the protocol, though. Why don't just allow a server to send less
data than requested (similar to what SCSI "GET LBA STATUS" allows) and
allow the server to choose the limit suitable for it (without directly
exposing it to the clients)?

> Paolo