Dear Max, Max Reitz <mre...@redhat.com> writes:
> 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. Hmm, seems like I didn't quite understand the way the test works then. @Kevin: Please do NOT queue this patch. @Max: From a cursory glance at the code, maybe your 1 *byte* per second rate limit is being rounded down to 0 *blocks* per second, with 0 meaning no limit? See e.g. mirror_set_speed(). Though I must admit I don't understand how speed=0 translates to unlimited (like qapi/block-core.json:block-job-set-speed says). My understanding of ratelimit_calculate_delay() is that speed=0 means "1 quantum per time slice", with time slice usually being 100ms; not sure about the quantum. Sascha -- Softwareentwicklung Sascha Silbe, Niederhofenstraße 5/1, 71229 Leonberg https://se-silbe.de/ USt-IdNr. DE281696641
