Am 06.04.2016 um 18:15 hat Max Reitz geschrieben: > 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.
We don't generally change test cases when they fail. Making a test case pass doesn't "fix things" per se. It only helps when the failure is a false positive. In this case, it looks like there might be a problem with block job throttling, so maybe we should look into that before changing the test? Kevin > > 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(-) >
pgpCbRzZJU0u4.pgp
Description: PGP signature
