Message ID | 20201026171815.13233-14-vsementsov@virtuozzo.com |
---|---|
State | New |
Headers | show |
Series | None | expand |
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>
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
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")
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(-)