[v3] backup performance: block_status + async

[PATCH v3 13/25] iotests: 129: prepare for backup over block-copy

Posted by Vladimir Sementsov-Ogievskiy 5 years ago

After introducing parallel async copy requests instead of plain
cluster-by-cluster copying loop, backup job may finish earlier than
final assertion in do_test_stop. Let's require slow backup explicitly
by specifying speed parameter.

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
---
 tests/qemu-iotests/129 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/qemu-iotests/129 b/tests/qemu-iotests/129
index 3c22f6448c..e9da0208c4 100755
--- a/tests/qemu-iotests/129
+++ b/tests/qemu-iotests/129
@@ -77,7 +77,7 @@ class TestStopWithBlockJob(iotests.QMPTestCase):
     def test_drive_backup(self):
         self.do_test_stop("drive-backup", device="drive0",
                           target=self.target_img,
-                          sync="full")
+                          sync="full", speed=1024)
 
     def test_block_commit(self):
         self.do_test_stop("block-commit", device="drive0")
-- 
2.21.3

Re: [PATCH v3 13/25] iotests: 129: prepare for backup over block-copy

Posted by Max Reitz 4 years, 10 months ago

On 26.10.20 18:18, Vladimir Sementsov-Ogievskiy wrote:
> After introducing parallel async copy requests instead of plain
> cluster-by-cluster copying loop, backup job may finish earlier than
> final assertion in do_test_stop. Let's require slow backup explicitly
> by specifying speed parameter.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> ---
>   tests/qemu-iotests/129 | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/qemu-iotests/129 b/tests/qemu-iotests/129
> index 3c22f6448c..e9da0208c4 100755
> --- a/tests/qemu-iotests/129
> +++ b/tests/qemu-iotests/129
> @@ -77,7 +77,7 @@ class TestStopWithBlockJob(iotests.QMPTestCase):
>       def test_drive_backup(self):
>           self.do_test_stop("drive-backup", device="drive0",
>                             target=self.target_img,
> -                          sync="full")
> +                          sync="full", speed=1024)
>   
>       def test_block_commit(self):
>           self.do_test_stop("block-commit", device="drive0")

I still don’t like this very much.  We write 128 MB of data, 
do_test_stop throttles the source to 1 kB/s, so even “a lot of parallel 
requests” shouldn’t finish immediately.

I feel like there’s a bigger problem here.

Then again, I have 129 disabled all the time anyway because its 
throttling simply doesn’t work, so I guess

Acked-by: Max Reitz <mreitz@redhat.com>

Re: [PATCH v3 13/25] iotests: 129: prepare for backup over block-copy

Posted by Vladimir Sementsov-Ogievskiy 4 years, 10 months ago

12.01.2021 15:14, Max Reitz wrote:
> On 26.10.20 18:18, Vladimir Sementsov-Ogievskiy wrote:
>> After introducing parallel async copy requests instead of plain
>> cluster-by-cluster copying loop, backup job may finish earlier than
>> final assertion in do_test_stop. Let's require slow backup explicitly
>> by specifying speed parameter.
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
>> ---
>>   tests/qemu-iotests/129 | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tests/qemu-iotests/129 b/tests/qemu-iotests/129
>> index 3c22f6448c..e9da0208c4 100755
>> --- a/tests/qemu-iotests/129
>> +++ b/tests/qemu-iotests/129
>> @@ -77,7 +77,7 @@ class TestStopWithBlockJob(iotests.QMPTestCase):
>>       def test_drive_backup(self):
>>           self.do_test_stop("drive-backup", device="drive0",
>>                             target=self.target_img,
>> -                          sync="full")
>> +                          sync="full", speed=1024)
>>       def test_block_commit(self):
>>           self.do_test_stop("block-commit", device="drive0")
> 
> I still don’t like this very much.  We write 128 MB of data, do_test_stop throttles the source to 1 kB/s, so even “a lot of parallel requests” shouldn’t finish immediately.
> 
> I feel like there’s a bigger problem here.

You were right!:) And finally I found it. Will fix in v4.

> 
> Then again, I have 129 disabled all the time anyway because its throttling simply doesn’t work, so I guess
> 
> Acked-by: Max Reitz <mreitz@redhat.com>
> 


-- 
Best regards,
Vladimir