Re: [Qemu-block] [Qemu-devel] [PATCH 3/3] qemu-iotests: Test exiting qemu with running job

[Kevin Wolf]

Am 09.06.2017 um 16:16 hat Eric Blake geschrieben:
> On 06/09/2017 07:58 AM, Kevin Wolf wrote:
> > Am 09.06.2017 um 14:14 hat Eric Blake geschrieben:
> >> On 06/09/2017 06:50 AM, Kevin Wolf wrote:
> >>> When qemu is exited, all running jobs should be cancelled successfully.
> >>> This adds a test for this for all types of block jobs that currently
> >>> exist in qemu.
> >>>
> >>> Signed-off-by: Kevin Wolf <address@hidden>
> 
> >>> +{"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, 
> >>> "event": "SHUTDOWN", "data": {"guest": false}}
> >>> +{"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, 
> >>> "event": "BLOCK_JOB_CANCELLED", "data": {"device": "disk", "len": 
> >>> 67108864, "offset": 524288, "speed": 65536, "type": "commit"}}
> >>
> >> I'm worried that if you don't sanitize at least offset, you will still
> >> be prone to some race conditions changing the output.  You may want to
> >> add in some additional filtering on the output to be safer.
> > 
> > I considered that at first, but then I realised that these offsets are
> > indeed predictable and we want to know if they change (it would likely
> > mean that the throttling is broken).
> > 
> > If you look at the individual cases, we have:
> > 
> > * offset=512k for (intermediate) commit and streaming. This is exactly
> >   the buffer size for a single request and will be followed by a delay
> >   of eight seconds before the next chunk is copied, so we will never get
> >   a different value here.
> > 
> > * offset=4M for active commit and mirror, because the mirror job has a
> >   larger buffer size by default, so one request completes it all. This
> >   number is already the maximum, so nothing is going to change here
> >   either.
> > 
> > * offset=64k for backup, which works cluster by cluster. We know that
> >   the cluster size is exactly 64k, and while we have only one second
> >   of delay here, that's still plenty of time for the 'quit' command to
> >   arrive.
> 
> These belong in comments in the test proper, because it is not obvious
> otherwise.  But with comments added (so someone debugging a theoretical
> test failure down the road knows what they are up against),

# Note that the reference output intentionally includes the 'offset' field in
# BLOCK_JOB_CANCELLED events for all of the following block jobs. They are
# predictable and any change in the offsets would hint at a bug in the job
# throttling code.
#
# In order to achieve these predictable offsets, all of the following tests
# use speed=65536. Each job will perform exactly one iteration before it has
# to sleep at least for a second, which is plenty of time for the 'quit' QMP
# command to be received (after receiving the command, the rest runs
# synchronously, so jobs can arbitrarily continue or complete).
#
# The buffer size for commit and streaming is 512k (waiting for 8 seconds after
# the first request), for active commit and mirror it's large enough to cover
# the full 4M, and for backup it's the qcow2 cluster size, which we know is
# 64k. As all of these are at least as large as the speed, we are sure that the
# offset doesn't advance after the first iteration before qemu exits.

Does this look okay?

Kevin

pgpT8zuWK2044.pgp
Description: PGP signature