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
