Re: [PATCH v4 15/18] iotests/image-fleecing: add test case with bitmap

[Hanna Reitz]

On 16.02.22 20:46, Vladimir Sementsov-Ogievskiy wrote:
> Note that reads zero areas (not dirty in the bitmap) fails, that's
> correct.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> ---
>   tests/qemu-iotests/tests/image-fleecing     | 32 ++++++--
>   tests/qemu-iotests/tests/image-fleecing.out | 84 +++++++++++++++++++++
>   2 files changed, 108 insertions(+), 8 deletions(-)

Looks good, just one general usage question:

> diff --git a/tests/qemu-iotests/tests/image-fleecing 
> b/tests/qemu-iotests/tests/image-fleecing
> index 909fc0a7ad..33995612be 100755
> --- a/tests/qemu-iotests/tests/image-fleecing
> +++ b/tests/qemu-iotests/tests/image-fleecing
> @@ -23,7 +23,7 @@
>   # Creator/Owner: John Snow <jsnow@redhat.com>
>   
>   import iotests
> -from iotests import log, qemu_img, qemu_io, qemu_io_silent
> +from iotests import log, qemu_img, qemu_io, qemu_io_silent, 
> qemu_io_pipe_and_status
>   
>   iotests.script_initialize(
>       supported_fmts=['qcow2', 'qcow', 'qed', 'vmdk', 'vhdx', 'raw'],
> @@ -50,11 +50,15 @@ remainder = [('0xd5', '0x108000',  '32k'), # Right-end of 
> partial-left [1]
>                ('0xcd', '0x3ff0000', '64k')] # patterns[3]
>   
>   def do_test(use_cbw, use_snapshot_access_filter, base_img_path,
> -            fleece_img_path, nbd_sock_path, vm):
> +            fleece_img_path, nbd_sock_path, vm,
> +            bitmap=False):
>       log('--- Setting up images ---')
>       log('')
>   
>       assert qemu_img('create', '-f', iotests.imgfmt, base_img_path, '64M') == 0
> +    if bitmap:
> +        assert qemu_img('bitmap', '--add', base_img_path, 'bitmap0') == 0
> +
>       if use_snapshot_access_filter:
>           assert use_cbw
>           assert qemu_img('create', '-f', 'raw', fleece_img_path, '64M') == 0
> @@ -106,12 +110,17 @@ def do_test(use_cbw, use_snapshot_access_filter, 
> base_img_path,
>   
>       # Establish CBW from source to fleecing node
>       if use_cbw:
> -        log(vm.qmp('blockdev-add', {
> +        fl_cbw = {
>               'driver': 'copy-before-write',
>               'node-name': 'fl-cbw',
>               'file': src_node,
>               'target': tmp_node
> -        }))
> +        }
> +
> +        if bitmap:
> +            fl_cbw['bitmap'] = {'node': src_node, 'name': 'bitmap0'}
> +
> +        log(vm.qmp('blockdev-add', fl_cbw))
>   
>           log(vm.qmp('qom-set', path=qom_path, property='drive', value='fl-cbw'))

This makes me wonder how exactly the @bitmap parameter is to be used.  
In this case here, we use an active bitmap that tracks all writes, so it 
looks like a case of trying to copy the changes since some previous 
checkpoint (as a point-in-time state).  But if there are any writes 
between the blockdev-add and the qom-set, then they will not be included 
in the CBW bitmap.  Is that fine?  Or is it perhaps even intentional?

(Is the idea that one would use a transaction to disable the current 
bitmap (say “A”), and add a new one (say “B”) at the same time, then use 
bitmap A for the CBW filter, delete it after the backup, and then use B 
for the subsequent backup?)