Re: [Qemu-devel] [PATCH v5 10/21] qmp: Add support of "dirty-bitmap" sync mode for drive-backup

[John Snow <jsnow@redhat.com>]

On 04/17/2015 06:51 PM, Eric Blake wrote:
> On 04/08/2015 04:19 PM, John Snow wrote:
>> For "dirty-bitmap" sync mode, the block job will iterate through the
>> given dirty bitmap to decide if a sector needs backup (backup all the
>> dirty clusters and skip clean ones), just as allocation conditions of
>> "top" sync mode.
>>
>> Signed-off-by: Fam Zheng <famz@redhat.com>
>> Signed-off-by: John Snow <jsnow@redhat.com>
>> ---
>>   block.c                   |   9 +++
>>   block/backup.c            | 156 +++++++++++++++++++++++++++++++++++++++-------
>>   block/mirror.c            |   4 ++
>>   blockdev.c                |  18 +++++-
>>   hmp.c                     |   3 +-
>>   include/block/block.h     |   1 +
>>   include/block/block_int.h |   2 +
>>   qapi/block-core.json      |  13 ++--
>>   qmp-commands.hx           |   7 ++-
>>   9 files changed, 180 insertions(+), 33 deletions(-)
>>
>
> Just reviewing the interface...
>
>> +++ b/qapi/block-core.json
>> @@ -512,10 +512,12 @@
>>   #
>>   # @none: only copy data written from now on
>>   #
>> +# @dirty-bitmap: only copy data described by the dirty bitmap. Since: 2.4
>> +#
>>   # Since: 1.3
>>   ##
>>   { 'enum': 'MirrorSyncMode',
>> -  'data': ['top', 'full', 'none'] }
>> +  'data': ['top', 'full', 'none', 'dirty-bitmap'] }
>>
>>   ##
>>   # @BlockJobType:
>> @@ -690,14 +692,17 @@
>>   #          probe if @mode is 'existing', else the format of the source
>>   #
>>   # @sync: what parts of the disk image should be copied to the destination
>> -#        (all the disk, only the sectors allocated in the topmost image, or
>> -#        only new I/O).
>> +#        (all the disk, only the sectors allocated in the topmost image, from a
>> +#        dirty bitmap, or only new I/O).
>>   #
>>   # @mode: #optional whether and how QEMU should create a new image, default is
>>   #        'absolute-paths'.
>>   #
>>   # @speed: #optional the maximum speed, in bytes per second
>>   #
>> +# @bitmap: #optional the name of dirty bitmap if sync is "dirty-bitmap"
>> +#          (Since 2.4)
>> +#
>>   # @on-source-error: #optional the action to take on an error on the source,
>>   #                   default 'report'.  'stop' and 'enospc' can only be used
>>   #                   if the block device supports io-status (see BlockInfo).
>> @@ -715,7 +720,7 @@
>>   { 'type': 'DriveBackup',
>>     'data': { 'device': 'str', 'target': 'str', '*format': 'str',
>>               'sync': 'MirrorSyncMode', '*mode': 'NewImageMode',
>> -            '*speed': 'int',
>> +            '*speed': 'int', '*bitmap': 'str',
>
> Looks okay.  Is it an error if bitmap is supplied, but mode is not
> dirty-bitmap?  Likewise, if mode is dirty-bitmap but bitmap is not supplied?
>

Yes:

+    if (sync_mode == MIRROR_SYNC_MODE_DIRTY_BITMAP) {
+        if (!sync_bitmap) {
+            error_setg(errp, "must provide a valid bitmap name for "
+                             "\"dirty-bitmap\" sync mode");
+            return;
+        }
+
[...]
+    } else if (sync_bitmap) {
+        error_setg(errp,
+                   "a sync_bitmap was provided to backup_run, "
+                   "but received an incompatible sync_mode (%s)",
+                   MirrorSyncMode_lookup[sync_mode]);
+        return;
+    }
+