On Fri, Mar 20, 2015 at 03:16:52PM -0400, John Snow wrote:
> A bitmap successor is an anonymous BdrvDirtyBitmap that is intended to
> be created just prior to a sensitive operation (e.g. Incremental Backup)
> that can either succeed or fail, but during the course of which we still
> want a bitmap tracking writes.
>
> On creating a successor, we "freeze" the parent bitmap which prevents
> its deletion, enabling, anonymization, or creating a bitmap with the
> same name.
>
> On success, the parent bitmap can "abdicate" responsibility to the
> successor, which will inherit its name. The successor will have been
> tracking writes during the course of the backup operation. The parent
> will be safely deleted.
>
> On failure, we can "reclaim" the successor from the parent, unifying
> them such that the resulting bitmap describes all writes occurring since
> the last successful backup, for instance. Reclamation will thaw the
> parent, but not explicitly re-enable it.
>
> BdrvDirtyBitmap operations that target a single bitmap are protected
> by assertions that the bitmap is not frozen and/or disabled.
>
> BdrvDirtyBitmap operations that target a group of bitmaps, such as
> bdrv_{set,reset}_dirty will ignore frozen/disabled drives with a
> conditional instead.
>
> QMP transactions that enable/disable bitmaps have extra error checking
> surrounding them that prevent modifying bitmaps that are frozen.
>
> Signed-off-by: John Snow <[email protected]>
> Reviewed-by: Max Reitz <[email protected]>
> ---
> block.c | 104
> +++++++++++++++++++++++++++++++++++++++++++++++++-
> blockdev.c | 7 ++++
> include/block/block.h | 10 +++++
> qapi/block-core.json | 1 +
> 4 files changed, 121 insertions(+), 1 deletion(-)Reviewed-by: Stefan Hajnoczi <[email protected]>
pgpsTlilkDLRu.pgp
Description: PGP signature
