On Thu, 9 Jul 2020 at 16:02, Kevin Wolf <kw...@redhat.com> wrote:
>
> We can "fix" it for probably all realistic cases by lowering the speed
> of the block job significantly. It's still not fully fixed for all
> theoretical cases, but the pattern of starting a block job that is
> throttled to a low speed so it will keep running for the next part of
> the test is very common.
>
> Kevin
>
> diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030
> index 256b2bfbc6..31c028306b 100755
> --- a/tests/qemu-iotests/030
> +++ b/tests/qemu-iotests/030
> @@ -243,7 +243,7 @@ class TestParallelOps(iotests.QMPTestCase):
> node_name = 'node%d' % i
> job_id = 'stream-%s' % node_name
> pending_jobs.append(job_id)
> - result = self.vm.qmp('block-stream', device=node_name,
> job_id=job_id, base=self.imgs[i-2], speed=512*1024)
> + result = self.vm.qmp('block-stream', device=node_name,
> job_id=job_id, base=self.imgs[i-2], speed=1024)
> self.assert_qmp(result, 'return', {})
>
> for job in pending_jobs:
Any chance we could get this fix into the tree? I've just
had an unrelated mergebuild test run hit this iotest 030
failure again...
-- PMM
