Buggy behavior with zone, random IOs since specific commit

Buggy behavior with zone, random IOs since specific commit

[Akash Verma]

This commit seems to have broken the behavior of random IOs with zone options:

4c8be5b1569f0aca8c7769803e57b79280d1f668

Using this example job file:
[zoned_out]
rw=read
bs=1k
offset=510k
ioengine=sync
zonesize=1k
zonerange=512k
zoneskip=512k
write_iolog=ios_meec.iolog
filename=10MFile

where 10M file was created as:
dd if=/dev/zero of=./10MFile bs=1M count=10

Prior to the above commit, FIO does one read per zone, and the job
exits after the last zone. This is as expected.

Post the above commit, FIO loops back to the first zone and may or may
not succeed in finding a valid offset to seek to. With offset=510k, it
fails on the first loop-back. With offset=100k, it fails on the
second; with no offset, it did about a 100 loops. With --debug=random,
I see messages like:

file     1885  get file 10MFile, ref=1
random   1885  off rand 1823528783
io       1885  get_next_offset: offset 18446744073708827648 >= size 10485760
io       1885  io_u 0x8c8e80, failed getting offset

There should be no loop-back happening at all unless this is specified
as desired (e.g. using runtime and time_based, or io_limit, or
number_ios).

Re: Buggy behavior with zone, random IOs since specific commit

[Jens Axboe]

On 03/18/2015 10:24 PM, Akash Verma wrote:
> This commit seems to have broken the behavior of random IOs with zone options:
>
> 4c8be5b1569f0aca8c7769803e57b79280d1f668
>
> Using this example job file:
> [zoned_out]
> rw=read
> bs=1k
> offset=510k
> ioengine=sync
> zonesize=1k
> zonerange=512k
> zoneskip=512k
> write_iolog=ios_meec.iolog
> filename=10MFile
>
> where 10M file was created as:
> dd if=/dev/zero of=./10MFile bs=1M count=10
>
> Prior to the above commit, FIO does one read per zone, and the job
> exits after the last zone. This is as expected.
>
> Post the above commit, FIO loops back to the first zone and may or may
> not succeed in finding a valid offset to seek to. With offset=510k, it
> fails on the first loop-back. With offset=100k, it fails on the
> second; with no offset, it did about a 100 loops. With --debug=random,
> I see messages like:
>
> file     1885  get file 10MFile, ref=1
> random   1885  off rand 1823528783
> io       1885  get_next_offset: offset 18446744073708827648 >= size 10485760
> io       1885  io_u 0x8c8e80, failed getting offset
>
> There should be no loop-back happening at all unless this is specified
> as desired (e.g. using runtime and time_based, or io_limit, or
> number_ios).

It might be more work, but yes, that I think is a good start. Care to 
send a patch to stop looping unless we're forced to? At least that will 
fix the case of buggy looping.

-- 
Jens Axboe

Re: Buggy behavior with zone, random IOs since specific commit

[Akash Verma]

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]

Hi Jens,
Apologies for the late response - it doesn't look like we'll be able to
work on this bug anytime soon.

On Fri, Mar 20, 2015 at 9:37 AM, Jens Axboe <axboe@kernel.dk> wrote:

> On 03/18/2015 10:24 PM, Akash Verma wrote:
>
>> This commit seems to have broken the behavior of random IOs with zone
>> options:
>>
>> 4c8be5b1569f0aca8c7769803e57b79280d1f668
>>
>> Using this example job file:
>> [zoned_out]
>> rw=read
>> bs=1k
>> offset=510k
>> ioengine=sync
>> zonesize=1k
>> zonerange=512k
>> zoneskip=512k
>> write_iolog=ios_meec.iolog
>> filename=10MFile
>>
>> where 10M file was created as:
>> dd if=/dev/zero of=./10MFile bs=1M count=10
>>
>> Prior to the above commit, FIO does one read per zone, and the job
>> exits after the last zone. This is as expected.
>>
>> Post the above commit, FIO loops back to the first zone and may or may
>> not succeed in finding a valid offset to seek to. With offset=510k, it
>> fails on the first loop-back. With offset=100k, it fails on the
>> second; with no offset, it did about a 100 loops. With --debug=random,
>> I see messages like:
>>
>> file     1885  get file 10MFile, ref=1
>> random   1885  off rand 1823528783
>> io       1885  get_next_offset: offset 18446744073708827648 >= size
>> 10485760
>> io       1885  io_u 0x8c8e80, failed getting offset
>>
>> There should be no loop-back happening at all unless this is specified
>> as desired (e.g. using runtime and time_based, or io_limit, or
>> number_ios).
>>
>
> It might be more work, but yes, that I think is a good start. Care to send
> a patch to stop looping unless we're forced to? At least that will fix the
> case of buggy looping.
>
> --
> Jens Axboe
>
>

[-- Attachment #2: Type: text/html, Size: 2326 bytes --]

Re: Buggy behavior with zone, random IOs since specific commit

[Akash Verma]

Hi Jens,
Apologies for the late response - it doesn't look like we'll be able
to work on this bug anytime soon.

On Fri, Mar 20, 2015 at 9:37 AM, Jens Axboe <axboe@kernel.dk> wrote:
> On 03/18/2015 10:24 PM, Akash Verma wrote:
>>
>> This commit seems to have broken the behavior of random IOs with zone
>> options:
>>
>> 4c8be5b1569f0aca8c7769803e57b79280d1f668
>>
>> Using this example job file:
>> [zoned_out]
>> rw=read
>> bs=1k
>> offset=510k
>> ioengine=sync
>> zonesize=1k
>> zonerange=512k
>> zoneskip=512k
>> write_iolog=ios_meec.iolog
>> filename=10MFile
>>
>> where 10M file was created as:
>> dd if=/dev/zero of=./10MFile bs=1M count=10
>>
>> Prior to the above commit, FIO does one read per zone, and the job
>> exits after the last zone. This is as expected.
>>
>> Post the above commit, FIO loops back to the first zone and may or may
>> not succeed in finding a valid offset to seek to. With offset=510k, it
>> fails on the first loop-back. With offset=100k, it fails on the
>> second; with no offset, it did about a 100 loops. With --debug=random,
>> I see messages like:
>>
>> file     1885  get file 10MFile, ref=1
>> random   1885  off rand 1823528783
>> io       1885  get_next_offset: offset 18446744073708827648 >= size
>> 10485760
>> io       1885  io_u 0x8c8e80, failed getting offset
>>
>> There should be no loop-back happening at all unless this is specified
>> as desired (e.g. using runtime and time_based, or io_limit, or
>> number_ios).
>
>
> It might be more work, but yes, that I think is a good start. Care to send a
> patch to stop looping unless we're forced to? At least that will fix the
> case of buggy looping.
>
> --
> Jens Axboe
>