From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53039) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoC5c-0000t2-4n for qemu-devel@nongnu.org; Thu, 07 Apr 2016 11:43:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aoC5b-0007ng-78 for qemu-devel@nongnu.org; Thu, 07 Apr 2016 11:43:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58314) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoC5b-0007mo-0w for qemu-devel@nongnu.org; Thu, 07 Apr 2016 11:43:23 -0400 References: <1459787950-15286-1-git-send-email-eblake@redhat.com> <20160405040527.GA4183@noname.redhat.com> <5703C0EC.6080306@redhat.com> <20160407153549.GA11233@phobos> From: Paolo Bonzini Message-ID: <57068014.3080209@redhat.com> Date: Thu, 7 Apr 2016 17:43:16 +0200 MIME-Version: 1.0 In-Reply-To: <20160407153549.GA11233@phobos> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pavel Borzenkov Cc: Kevin Wolf , nbd-general@lists.sourceforge.net, qemu-devel@nongnu.org, Stefan Hajnoczi , "Denis V. Lunev" , Wouter Verhelst On 07/04/2016 17:35, Pavel Borzenkov 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)? Yes, definitely. The number was just an example. Even 1 would be fine. Paolo