On 10 September 2017 at 03:32, Brandon Schwartz <schwartz.xn@xxxxxxxxx> wrote: > 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. I'd file this as an issue on github so it doesn't completely slip through the net. -- Sitsofe | http://sucs.org/~sits/ -- 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
