Paolo Bonzini <pbonz...@redhat.com> 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?
