Re: [Qemu-devel] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

[Kevin Wolf <kwolf@redhat.com>]

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 <pborzenkov@virtuozzo.com>
> CC: Denis V. Lunev <den@openvz.org>
> CC: Wouter Verhelst <w@uter.be>
> CC: Paolo Bonzini <pbonzini@redhat.com>
> CC: Kevin Wolf <kwolf@redhat.com>
> CC: Stefan Hajnoczi <stefanha@redhat.com>
> Signed-off-by: Eric Blake <eblake@redhat.com>

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