On Thu, Sep 7, 2017 at 11:22 PM, Sitsofe Wheeler <sitsofe@xxxxxxxxx> wrote: > On 8 September 2017 at 06:10, Brandon Schwartz <schwartz.xn@xxxxxxxxx> wrote: >> On Thu, Sep 7, 2017 at 10:46 PM, Sitsofe Wheeler <sitsofe@xxxxxxxxx> wrote: >>> >>> On 8 September 2017 at 01:13, Brandon Schwartz <schwartz.xn@xxxxxxxxx> wrote: >>>> >>>> Running the following job file with --io_submit_mode=offload set will >>>> occasionally give a 'No I/O performed by libaio' error > [...] >>>> >>>> After a few minutes of running FIO will exit with the following >>>> message: "No I/O performed by libaio, perhaps try --debug=io option >>>> for details" >>>> >>>> With debug set, I see this near the end of the trace: >>>> >>>> io 7720 io complete: io_u 0x55e10ee4abc0: >>>> off=1304219746304/len=65536/ddir=1io 7720 //dev/sdbio >>>> 7720 >>>> io 7720 fill_io_u: io_u 0x55e10ee4abc0: >>>> off=233107357696/len=0/ddir=0io 7720 //dev/sdbio 7720 >>> >>> That's weird - fio tried to submit a zero length read. How big was your device? >> >> It's a 2TB drive > > OK this seems to reproduce the problem: > > ./fio --debug=io --name=zerolenread --size=1M --rw=randread > --bs=128k,64k --ioengine=libaio --io_submit_mode=offload > --filename=/tmp/zerolenread > > Perhaps offload is generating bad random offsets when the blocksizes > between directions are different? > I tried digging into the code to see what's going on, but I'm not having much luck. Adding --norandommap to the job file will at least get around the error/zero length transfer. -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
