Dear Kevin,
Kevin Wolf writes:
> Am 08.04.2016 um 14:01 hat Sascha Silbe geschrieben:
[...]
>> The best approach probably would be to fix up the rate limit code to
>> delay for multiple time slices if necessary. We should get rid of the
>> artificial BDRV_SECTOR_SIZE granularity at the same time
Am 08.04.2016 um 14:01 hat Sascha Silbe geschrieben:
> Dear Max,
>
> Sascha Silbe writes:
>
> > @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
Dear Max,
Sascha Silbe writes:
> @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 unlimit
Am 07.04.2016 um 22:27 hat Sascha Silbe geschrieben:
> Dear Max,
>
> Max Reitz 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
Dear Max,
Max Reitz 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
>>
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 t
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 comm
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
