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

[Eric Blake]

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),

Reviewed-by: Eric Blake <address@hidden>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature