From: Jens Axboe <axboe@kernel.dk>
To: Jeff Furlong <jeff.furlong@hgst.com>,
Jens Rosenboom <j.rosenboom@x-ion.de>,
Sitsofe Wheeler <sitsofe@gmail.com>
Cc: "fio@vger.kernel.org" <fio@vger.kernel.org>
Subject: Re: time_based option broken
Date: Thu, 14 Jan 2016 13:22:07 -0700 [thread overview]
Message-ID: <5698036F.9000700@kernel.dk> (raw)
In-Reply-To: <569800D2.1010406@kernel.dk>
On 01/14/2016 01:10 PM, Jens Axboe wrote:
> On 01/14/2016 12:51 PM, Jeff Furlong wrote:
>> Latest commit seems to help, but found one more issue:
>>
>> # blockdev --getsize64 /dev/nvme2n1
>> 800166076416
>>
>> 800166076416B = 763097.8MB
>>
>> Test1: Round io_size to match bs: PASS
>> # ./fio/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-26-g19dd
>> Starting 1 process
>> Jobs: 1 (f=1): [W(1)] [100.0% done] [0KB/1380MB/0KB /s] [0/1380/0
>> iops] [eta 00m:00s]
>> SW_1MB_QD32: (groupid=0, jobs=1): err= 0: pid=80311: Thu Jan 14
>> 10:11:36 2016
>> write: io=84966MB, bw=1415.1MB/s, iops=1415, runt= 60009msec
>>
>> Test2: Loop around max device size and continue IO with fixed runtime:
>> PASS
>> # ./fio/fio --name=SW_1MB_QD32 --ioengine=libaio --direct=1 --rw=write
>> --iodepth=32 --size=100% --runtime=15m --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-26-g19dd
>> Starting 1 process
>> Jobs: 1 (f=1): [W(1)] [100.0% done] [0KB/1388MB/0KB /s] [0/1388/0
>> iops] [eta 00m:00s]
>> SW_1MB_QD32: (groupid=0, jobs=1): err= 0: pid=80377: Thu Jan 14
>> 10:28:27 2016
>> write: io=1231.9GB, bw=1401.6MB/s, iops=1401, runt=900008msec
>>
>> Test3: Loop around max device size and continue IO with fixed total
>> IO, round total IO to bs: FAIL (does not loop around to start LBA)
>> # ./fio/fio --name=SW_1MB_QD32 --ioengine=libaio --direct=1 --rw=write
>> --iodepth=32 --size=100% --io_size=810000000000 --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-26-g19dd
>> Starting 1 process
>> Jobs: 1 (f=0): [W(1)] [98.9% done] [0KB/1453MB/0KB /s] [0/1453/0 iops]
>> [eta 00m:06s]
>> SW_1MB_QD32: (groupid=0, jobs=1): err= 0: pid=81065: Thu Jan 14
>> 10:49:53 2016
>> write: io=763097MB, bw=1399.5MB/s, iops=1399, runt=545278msec
>>
>> Test4: Loop around max device size and continue IO with fixed total
>> IO, total IO is already aligned to bs: FAIL (does not loop around to
>> start LBA)
>> # ./fio/fio --name=SW_1MB_QD32 --ioengine=libaio --direct=1 --rw=write
>> --iodepth=32 --size=100% --io_size=810675077120 --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-26-g19dd
>> Starting 1 process
>> Jobs: 1 (f=1): [W(1)] [98.6% done] [0KB/1404MB/0KB /s] [0/1404/0 iops]
>> [eta 00m:08s]
>> SW_1MB_QD32: (groupid=0, jobs=1): err= 0: pid=81339: Thu Jan 14
>> 11:01:57 2016
>> write: io=763097MB, bw=1399.9MB/s, iops=1399, runt=545142msec
>
> Very strange, I can't reproduce 3/4 test case failures. I've got a small
> nvme0n1 device here:
>
> axboe@dell:~ $ sudo blockdev --getsize64 /dev/nvme0n1
> 4286578688
>
> and I tried:
>
> ./fio --name=SW_1MB_QD32 --ioengine=libaio --direct=1 --rw=write
> --iodepth=1 --size=100% --io_size=4386578688 --numjobs=1 --bs=1m
> --overwrite=1 --filename=/dev/nvme0n1
>
> and 4300000000 for sizes, and it produces the desired outcome in writing
> the bytes specified by io_size. I added a quick dump to the offset, and
> that looks correct too:
>
> [...]
> off=4281335808
> off=4282384384
> off=4283432960
> off=4284481536
> off=4285530112
> off=0
> off=1048576
> off=2097152
> off=3145728
> [...]
>
> which loops around and starts writing from 0 again.
>
> I'll try a bigger device, though it'd be weird if that behaved differently.
It does reproduce with a bigger device, just not on the 4G/16G ones I
have. Very odd, but at least I can reproduce it.
--
Jens Axboe
next prev parent reply other threads:[~2016-01-14 20:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-06 18:45 time_based option broken Jeff Furlong
2016-01-07 6:03 ` Sitsofe Wheeler
2016-01-08 14:03 ` Jens Rosenboom
2016-01-08 19:35 ` Jeff Furlong
2016-01-14 17:33 ` Jens Axboe
2016-01-14 19:51 ` Jeff Furlong
2016-01-14 20:10 ` Jens Axboe
2016-01-14 20:22 ` Jens Axboe [this message]
2016-01-14 21:46 ` Jens Axboe
2016-01-14 23:04 ` Jeff Furlong
2016-01-15 15:41 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5698036F.9000700@kernel.dk \
--to=axboe@kernel.dk \
--cc=fio@vger.kernel.org \
--cc=j.rosenboom@x-ion.de \
--cc=jeff.furlong@hgst.com \
--cc=sitsofe@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.