From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37235) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anIFE-0006Xd-Tu for qemu-devel@nongnu.org; Tue, 05 Apr 2016 00:05:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anIFA-0003rz-Nr for qemu-devel@nongnu.org; Tue, 05 Apr 2016 00:05:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36558) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anIFA-0003qo-Bn for qemu-devel@nongnu.org; Tue, 05 Apr 2016 00:05:32 -0400 Date: Tue, 5 Apr 2016 06:05:27 +0200 From: Kevin Wolf Message-ID: <20160405040527.GA4183@noname.redhat.com> References: <1459787950-15286-1-git-send-email-eblake@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1459787950-15286-1-git-send-email-eblake@redhat.com> 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: Eric Blake Cc: nbd-general@lists.sourceforge.net, qemu-devel@nongnu.org, Pavel Borzenkov , Stefan Hajnoczi , Paolo Bonzini , Wouter Verhelst , "Denis V. Lunev" Am 04.04.2016 um 18:39 hat Eric Blake geschrieben: > With the availability of sparse storage formats, it is often needed > to query status of a particular range and read only those blocks of > data that are actually present on the block device. > > To provide such information, the patch adds the BLOCK_STATUS > extension with one new NBD_CMD_BLOCK_STATUS command, a new > structured reply chunk format, and a new transmission flag. > > There exists a concept of data dirtiness, which is required > during, for example, incremental block device backup. To express > this concept via NBD protocol, this patch also adds a flag to > NBD_CMD_BLOCK_STATUS to request dirtiness information rather than > provisioning information; however, with the current proposal, data > dirtiness is only useful with additional coordination outside of > the NBD protocol (such as a way to start and stop the server from > tracking dirty sectors). Future NBD extensions may add commands > to control dirtiness through NBD. > > Since NBD protocol has no notion of block size, and to mimic SCSI > "GET LBA STATUS" command more closely, it has been chosen to return > a list of extents in the response of NBD_CMD_BLOCK_STATUS command, > instead of a bitmap. > > CC: Pavel Borzenkov > CC: Denis V. Lunev > CC: Wouter Verhelst > CC: Paolo Bonzini > CC: Kevin Wolf > CC: Stefan Hajnoczi > Signed-off-by: Eric Blake I think there is one common type of request that clients can't implement efficiently with this proposal: Give me the status and the length of the next extent of blocks with the same status. This is essentially how bdrv_get_block_status() works in qemu, so we want an efficient way to do this. With this proposal, if I understand correctly, we could either send short NBD_CMD_BLOCK_STATUS requests and risk being inefficient because we need many calls for a large area with the same status; or, if we send a large NBD_CMD_BLOCK_STATUS request, we may get a ridiculously long reply (with the corresponding overhead on the server to compose the list) while we're only really interested in the first descriptor. 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. Kevin