On 05.04.2016 11:21, Sascha Silbe wrote: > On systems with fast IO, qemu-io may write more than 1 MiB before > receiving the block-job-cancel command, causing the test case to fail. > > 141 is inherently racy, but we can at least reduce the likelihood of the > job completing before the cancel command arrives by bumping the size of > the data getting written; we'll try 32 MiB for a start.
Hm, interesting. I tried to prevent this by setting the block jobs' speed to 1, which should make it stop after the block job has processed the first block of data. I won't oppose this patch, because if it fixes things for you, that's good. But I don't think it should be necessary. Max > > Once we actually move enough data around for the block job not to > complete prematurely, the test will still fail because the offset value > in the BLOCK_JOB_CANCELLED event will vary. Since this is more or less > inherent to the nature of this event, we just replace it with a fixed > value globally (in _filter_qmp), the same way we handle timestamps. > > Signed-off-by: Sascha Silbe <si...@linux.vnet.ibm.com> > Reviewed-by: Bo Tu <t...@linux.vnet.ibm.com> > --- > tests/qemu-iotests/141 | 11 ++++++----- > tests/qemu-iotests/141.out | 24 ++++++++++++------------ > tests/qemu-iotests/common.filter | 1 + > 3 files changed, 19 insertions(+), 17 deletions(-)
signature.asc
Description: OpenPGP digital signature