From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47290) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjEyq-0002j4-HY for qemu-devel@nongnu.org; Fri, 17 Apr 2015 18:43:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YjEym-00006u-Gs for qemu-devel@nongnu.org; Fri, 17 Apr 2015 18:43:24 -0400 Message-ID: <55318C85.7000909@redhat.com> Date: Fri, 17 Apr 2015 16:43:17 -0600 From: Eric Blake MIME-Version: 1.0 References: <1428531604-9428-1-git-send-email-jsnow@redhat.com> <1428531604-9428-10-git-send-email-jsnow@redhat.com> In-Reply-To: <1428531604-9428-10-git-send-email-jsnow@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lwMLmVesa8o1McwcQtk0ejEhdQpV78q4B" Subject: Re: [Qemu-devel] [PATCH v5 09/21] block: Add bitmap successors List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow , qemu-block@nongnu.org Cc: kwolf@redhat.com, famz@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, vsementsov@parallels.com, stefanha@redhat.com, mreitz@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lwMLmVesa8o1McwcQtk0ejEhdQpV78q4B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/08/2015 04:19 PM, 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 stil= l > want a bitmap tracking writes. >=20 > On creating a successor, we "freeze" the parent bitmap which prevents > its deletion, enabling, anonymization, or creating a bitmap with the > same name. >=20 > 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. >=20 > On failure, we can "reclaim" the successor from the parent, unifying > them such that the resulting bitmap describes all writes occurring sinc= e > the last successful backup, for instance. Reclamation will thaw the > parent, but not explicitly re-enable it. >=20 > BdrvDirtyBitmap operations that target a single bitmap are protected > by assertions that the bitmap is not frozen and/or disabled. >=20 > BdrvDirtyBitmap operations that target a group of bitmaps, such as > bdrv_{set,reset}_dirty will ignore frozen/disabled drives with a > conditional instead. >=20 > QMP transactions that enable/disable bitmaps have extra error checking > surrounding them that prevent modifying bitmaps that are frozen. Is this last paragraph stale now? >=20 > Signed-off-by: John Snow > Reviewed-by: Max Reitz > Reviewed-by: Stefan Hajnoczi > --- > block.c | 104 ++++++++++++++++++++++++++++++++++++++++++= +++++++- > blockdev.c | 7 ++++ > include/block/block.h | 10 +++++ > qapi/block-core.json | 1 + > 4 files changed, 121 insertions(+), 1 deletion(-) >=20 > +/** > + * A BdrvDirtyBitmap can be in three possible states: > + * (1) successor is false and disabled is false: full r/w mode > + * (2) successor is false and disabled is true: read only mode ("disab= led") > + * (3) successor is set: frozen mode. > + * A frozen bitmap cannot be renamed, deleted, anonymized, cleared= , set, > + * or enabled. A frozen bitmap can only abdicate() or reclaim(). > + */ > struct BdrvDirtyBitmap { > HBitmap *bitmap; > + BdrvDirtyBitmap *successor; 'successor is false' reads awkwardly given that it is not a bool; maybe 'successor is NULL' is better? > =20 > +bool bdrv_dirty_bitmap_frozen(BdrvDirtyBitmap *bitmap) > +{ > + return bitmap->successor; Good thing C99 requires conversion of pointer to bool to work :) > + > +/** > + * For a bitmap with a successor, yield our name to the successor, > + * Delete the old bitmap, and return a handle to the new bitmap. Sentences with capitals after comma, Even with a line break, Look weird. (s/Delete/delete/) > + > +/** > + * In cases of failure where we can no longer safely delete the parent= , > + * We may wish to re-join the parent and child/successor. and again (s/We/we/) Grammar fixes are minor, so: Reviewed-by: Eric Blake --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --lwMLmVesa8o1McwcQtk0ejEhdQpV78q4B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVMYyFAAoJEKeha0olJ0NqC/YH+wd5PwmL9GbfX3GClgVPUTxA +i0NOTGLzF3WrW/MThYKnvNY2DWL4vPpc7cdfDLqIso8nNYJaFOZTsTYGTfZ27sF svzpwzSbE/ZMJJgo9DilJerZ7EA7Mi4xmFTdICetPsRpAId8XP0fOl0on/qEp6iW PvxHhBBy1IEBWjTpxGx2d6csbi+RHPjU3u55d4k3CCurVYS7iWO1gwztk0py8gUk R8m4SbIMCI91c8cmtZtj1y4QspRUxaDLzNzyKdSXhfXnLnWFdT0U08lgLqW1+GJa O/Ooy7yGUBkGWKzKRRGv1Khr42EdrYYQi8rM1v8N8qEdU1a1ETwSRub9rZCl0Xs= =8fJb -----END PGP SIGNATURE----- --lwMLmVesa8o1McwcQtk0ejEhdQpV78q4B--