On 03/27/2014 03:09 AM, Fam Zheng wrote: > This adds dirty-bitmap-add and dirty-bitmap-disable to transactions. > With this, user can stop a dirty bitmap, start backup of it, and start > another dirty bitmap atomically, so that the dirty bitmap is tracked > incrementally and we don't miss any write.
Ah, this addresses my question in 7/9 about atomicity of creating a map in disabled state. Nice idea to use 'transaction' to merge the two commands, instead of having to bloat the creation with ever more options. > > Signed-off-by: Fam Zheng <f...@redhat.com> > --- > blockdev.c | 68 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > qapi-schema.json | 4 +++- > 2 files changed, 71 insertions(+), 1 deletion(-) > > +++ b/qapi-schema.json > @@ -1994,7 +1994,9 @@ > 'blockdev-snapshot-sync': 'BlockdevSnapshot', > 'drive-backup': 'DriveBackup', > 'abort': 'Abort', > - 'blockdev-snapshot-internal-sync': 'BlockdevSnapshotInternal' > + 'blockdev-snapshot-internal-sync': 'BlockdevSnapshotInternal', > + 'dirty-bitmap-add': 'DirtyBitmap', > + 'dirty-bitmap-disable': 'DirtyBitmap' > } } However, shouldn't it ALSO be possible to enable a bitmap in tandem with other transaction operations? I can imagine a transaction that both kicks off a snapshot and enables a bitmap that was previously added but left disabled. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
