On 2018-06-06 20:37, Max Reitz wrote: > 219 has two issues that may lead to sporadic failure, both of which are > the result of issuing query-jobs too early after a job has been > modified. This can then lead to different results based on whether the > modification has taken effect already or not. > > First, query-jobs is issued right after the job has been created. > Besides its current progress possibly being in any random state (which > has already been taken care of), its total progress too is basically > arbitrary, because the job may not yet have been able to determine it. > This patch addresses this by just filtering the total progress, like > what has been done for the current progress already. However, for more > clarity, the filtering is changed to replace the values by a string > 'FILTERED' instead of deleting them. > > Secondly, query-jobs is issued right after a job has been resumed. The > job may or may not yet have had the time to actually perform any I/O, > and thus its current progress may or may not have advanced. To make > sure it has indeed advanced (which is what the reference output already > assumes), insert a sleep of 100 ms before query-jobs is invoked. With a > slice time of 100 ms, a buffer size of 64 kB and a speed of 256 kB/s, > this should be the right amount of time to let the job advance by > exactly 64 kB. > > Signed-off-by: Max Reitz <mre...@redhat.com> > --- > v2: Changed the query-jobs progress filtering [Eric] > --- > tests/qemu-iotests/219 | 12 ++++++++---- > tests/qemu-iotests/219.out | 10 +++++----- > 2 files changed, 13 insertions(+), 9 deletions(-)
Oops, forgot the "v2" tag. Forgive me. Max
signature.asc
Description: OpenPGP digital signature
