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 <pborzen...@virtuozzo.com> > CC: Denis V. Lunev <d...@openvz.org> > CC: Wouter Verhelst <w...@uter.be> > CC: Paolo Bonzini <pbonz...@redhat.com> > CC: Kevin Wolf <kw...@redhat.com> > CC: Stefan Hajnoczi <stefa...@redhat.com> > Signed-off-by: Eric Blake <ebl...@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