On 02/26/2016 10:55 PM, Paolo Bonzini wrote:

On 19/02/2016 09:51, Markus Armbruster wrote:
Is it an abuse to "Get LBA Status" to return dirty information? Because in SCSI
the command reports "mapped", "allocated" and "anchored" statuses. Does that
mean NBD will use a different status set?
Perhaps some conceptual gymnastics can get us to standard semantics.

Incremental backup wants to copy out an image's "dirty" blocks.

We can view this as a bitmap telling us which of the image's blocks are
dirty.

An alternative view would be base image + dirty delta image.  In the the
dirty delta, exactly the dirty blocks are allocated.  The delta image
may be conceptual.
I see a problem here. On one hand I agree that the "GET LBA STATUS" is
a natural extension to the NBD protocol.

On the other hand, the Get LBA Status command in SCSI reflects the
state over the whole chain, not only the top element.  It is the
equivalent of bdrv_get_block_status_above(bs, NULL, ...), rather than
bdrv_get_block_status(bs, ...).  My understanding is that the dirty
block information would require the latter, especially in the
"conceptual delta image" model that Markus describes above.

Having NBD implement subtly different semantics compared to SCSI is a
bad idea in my opinion.

Of course if we call it "READ DIRTY BLOCKS" that would work, but I
don't think such a command would be something that it makes sense to
have in the general purpose NBD spec, so you would need a mechanism
for vendor-specific extensions.

Paolo

In general, the idea to bind DIRTY BITMAP to GET STATUS command is not that
bad. First of all, NBD has no relation to the SCSI at all thus we are not
bound to the SCSI protocol. This is good thing.

Next, it is generally good to query state of the data block before reading
to reduce amount of transfers over the network. This is useful even for a
full backup operation to avoid zero block transfers.

Thus, if we have created special NBD share, we can provide STATUS bitmap
in the way we want, f.e. with the proposed semantics. This will not be a
violation of the protocol.

Den

Reply via email to