Re: [Qemu-devel] [PATCH v2 0/6] external backup api

[Markus Armbruster]

Paolo Bonzini <address@hidden> writes:

> 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.

I completely agree with you that Get LBA Status cannot just reflect the
top layer.  But that's not what I meant to propose.  Let me try to
explain myself more clearly.

Consider a QCOW2 image D (for delta) with a backing file B (for base).
If you open it normally, you see "D over B".  Get LBA Status should
certainly claim the "deallocated" state only for blocks that are
allocated neither in D nor B.

However, you can also open D *without* its backing file.  Then you see
"D over nothing".  Here, get LBA Status should claim "deallocated" state
for anything not allocated in D.

My proposal is to expose a "just the dirty blocks" view of a block
backend similarly: it's a *separate* backend that contains *only* the
dirty blocks.  Attempts to read a clean block behave exactly like
reading an unmapped block from any other thinly provisioned backend
(QCOW2 gives you zeroes, if I remember correctly).  I think it's only
natural to make Get LBA Status claim "deallocated" for exactly the clean
blocks then.

> 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
>
>> Now, consider the dirty delta *without* its backing image.  You can find
>> its allocated blocks with Get LBA Status.  As usual, you can read even
>> unallocated blocks, see SBC3 table 9.
>> 
>> If we NBD-export exactly that, we can use standard semantics, can't we?