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

[Wouter Verhelst <w@uter.be>]

On Mon, Apr 04, 2016 at 10:54:02PM +0300, Denis V. Lunev wrote:
> saying about dirtiness, we would soon come to the fact, that
> we can have several dirtiness states regarding different
> lines of incremental backups. This complexity is hidden
> inside QEMU and it would be very difficult to publish and
> reuse it.

How about this then.

A reply to GET_BLOCK_STATUS containing chunks of this:

32-bit length
32-bit "snapshot status"
if bit 0 in the latter field is set, that means the block is allocated
  on the original device
if bit 1 is set, that means the block is allocated on the first-level
  snapshot
if bit 2 is set, that means the block is allocated on the second-level
  snapshot

etc

If all flags are cleared, that means the block is not allocated (i.e.,
is a hole) and MUST read as zeroes.

If a flag is set at a particular level X, that means the device is dirty
at the Xth-level snapshot.

If at least one flag is set for a region, that means the data may read
as "not zero".

The protocol does not define what it means to have multiple levels of
snapshots, other than:

- Any write command (WRITE or WRITE_ZEROES) MUST NOT clear or set the
  Xth level flag if the Yth level flag is not also cleared at the same
  time, for any Y > X
- Any write (as above) MAY set or clear multiple levels of flags at the
  same time, as long as the above holds

Having a 32-bit snapshot status field allows for 32 levels of snapshots.
We could switch length and flags to 64 bits so that things continue to
align nicely, and then we have a maximum of 64 levels of snapshots.

(I'm not going to write this up formally at this time of night, but you
get the general idea)

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12