Am 15.05.2019 um 22:14 hat Max Reitz geschrieben:
> 245 is a bit flakey for me, because it uses block jobs that copy 1 MB of
> data but have a buffer size of 512 kB, so they may be done before the
> test gets to do the things it wants to do while the check is running.
> (Rate limiting doesn’t change this.)
> The boring way to fix this would be to increase the amount of data.
> The interesting way to fix this is to make use of auto_finalize=false
> and thus keep the jobs around until the test is done with them.
> However, this has one problem: In one case, 245 tries to make the target
> node of a stream job read-only.  If the job is still copying data, doing
> so will fail because the target node is in COR mode.  Otherwise, we get
> a cryptic “Block node is read-only” message.
> What the message means is “After reopening, the node will be read-only,
> and that won’t work, because there is a writer on it.”  It doesn’t say
> that, though, but it should.  So patch 1 makes it say something to that
> effect (“Cannot make block node read-only, there is a writer on it”).
> 245 doesn’t care about the actual error message, both reflect that qemu
> correctly detects that this node cannot be made read-only at this time.
> So the other thing we have to do is let assert_qmp() accept an array of
> valid error messages and choose the one that matches (if any).  Then we
> can just pass both error messages to it and everything works.
> Nice side effect: For me, the test duration goes down from about 12 s to
> about 6 s.
> (That’s because the test forgot to disable rate limiting on the jobs
> before waiting for their completion.)

Thanks, applied to the block branch.


Reply via email to