qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/4] iotests: Make 245 faster and more reliable


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 0/4] iotests: Make 245 faster and more reliable
Date: Mon, 20 May 2019 16:18:20 +0200
User-agent: Mutt/1.11.3 (2019-02-01)

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.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]