Good points. Here is further data:
# blockdev --getsize64 /dev/nvme2n1
800166076416
# fio --name=SW_1MB_QD32 --ioengine=libaio --direct=1 --rw=write --iodepth=32 --size=1000m --runtime=60s --time_based --numjobs=1 --bs=1m --overwrite=1 --filename=/dev/nvme2n1
SW_1MB_QD32: (g=0): rw=write, bs=1M-1M/1M-1M/1M-1M, ioengine=libaio, iodepth=32
fio-2.3-11-g5f3b
Starting 1 process
Jobs: 1 (f=1): [W(1)] [100.0% done] [0KB/990.2MB/0KB /s] [0/990/0 iops] [eta 00m:00s]
SW_1MB_QD32: (groupid=0, jobs=1): err= 0: pid=19511: Fri Jan 8 11:08:55 2016
write: io=58620MB, bw=976.11MB/s, iops=976, runt= 60001msec
So the above using a fixed --size that is compatible with --bs is one workaround.
When trying to write more than 100% of the device (wrapping around after end of device), instead of --size=100% we could use a fixed size (where above 800166076416 bytes is 763097.8 MB), even if time_based is not used (use --io_size instead):
# fio --name=SW_1MB_QD32 --ioengine=libaio --direct=1 --rw=write --iodepth=32 --size=763097m --io_size=764000m --numjobs=1 --bs=1m --overwrite=1 --filename=/dev/nvme2n1
SW_1MB_QD32: (g=0): rw=write, bs=1M-1M/1M-1M/1M-1M, ioengine=libaio, iodepth=32
fio-2.3-11-g5f3b
Starting 1 process
Jobs: 1 (f=1): [W(1)] [100.0% done] [0KB/567.9MB/0KB /s] [0/567/0 iops] [eta 00m:00s]
SW_1MB_QD32: (groupid=0, jobs=1): err= 0: pid=129928: Thu Jan 7 12:45:52 2016
write: io=764000MB, bw=600510KB/s, iops=586, runt=1302786msec
Alternatively, if we simply back out the commit c82ea3d49aa then we can make the 1% or 100% options (--time_based or --io_size) work fine:
# fio --name=SW_1MB_QD32 --ioengine=libaio --direct=1 --rw=write --iodepth=32 --size=1% --runtime=60s --time_based --numjobs=1 --bs=1m --overwrite=1 --filename=/dev/nvme2n1
SW_1MB_QD32: (g=0): rw=write, bs=1M-1M/1M-1M/1M-1M, ioengine=libaio, iodepth=32
fio-2.3-11-g5f3b
Starting 1 process
Jobs: 1 (f=1): [W(1)] [100.0% done] [0KB/954.2MB/0KB /s] [0/954/0 iops] [eta 00m:00s]
SW_1MB_QD32: (groupid=0, jobs=1): err= 0: pid=21853: Fri Jan 8 11:20:04 2016
write: io=56931MB, bw=971606KB/s, iops=948, runt= 60001msec
Thanks.
Regards,
Jeff
> Hi,
>>
>> Here is 2.3 with a --runtime of 60s, and a runt of only 16s, and an error:
>>
>> # fio --name=SW_1MB_QD32 --ioengine=libaio --direct=1 --rw=write
>> --iodepth=32 --size=1% --runtime=60s --time_based --numjobs=1 --bs=1m
>> --overwrite=1 --filename=/dev/nvme0n1
>> SW_1MB_QD32: (g=0): rw=write, bs=1M-1M/1M-1M/1M-1M, ioengine=libaio,
>> iodepth=32 fio-2.3-11-g5f3b Starting 1 process
>> fio: io_u error on file /dev/nvme0n1: Invalid argument: write
>> offset=153764, buflen=1048576
>> fio: io_u error on file /dev/nvme0n1: Invalid argument: write
>> offset=1202340, buflen=1048576
>> fio: pid=68391, err=22/file:io_u.c:1596, func=io_u error,
>> error=Invalid argument
>>
>> SW_1MB_QD32: (groupid=0, jobs=1): err=22 (file:io_u.c:1596, func=io_u
>> error, error=Invalid argument): pid=68391: Wed Jan 6 08:48:18 2016
>
> Can say how big /dev/nvme0n1 is and can you repeat your test but with
> size set in bytes? I'm wondering if your 1MByte blocksize doesn't
> divide evenly in the 1% space the job has to work with...
Indeed I can pretty easily reproduce this by setting size to some odd value. git bisect then finds c82ea3d49aa as the culprit.
HGST E-mail Confidentiality Notice & Disclaimer:
This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.
��.n��������+%������w��{.n�������^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
