Thanks for the patch Jens, without the patch: [0.0% done] [399.2MB/933.2MB/0KB /s] [102K/239K/0 iops] with the patch: [0.0% done] [2629MB/6158MB/0KB /s] [30.3K/70.7K/0 iops] This looks like it corrected the issue. Thank you for your time and support, have a great weekend! Ryan On Fri, Sep 16, 2016 at 8:14 AM, Jens Axboe <axboe@xxxxxxxxx> wrote: > On 09/15/2016 11:01 AM, Ryan Stiles wrote: >> >> Good day, >> >> We have automation that uses the "bssplit" function to get a wide >> variety of IO patterns, I have noticed that in 2.13 (compiled with >> no-shared-mem). The bsssplit only takes the first variable, meaning: >> >> bssplit=1k/50:128k/50 >> >> will yield a 100% 1k workload. >> >> This is the workload: >> [global] >> random_generator=tausworthe64 >> direct=1 >> loops=1 >> ioengine=libaio >> iodepth=16 >> group_reporting >> filename=/dev/disk/by-uuid/27602b49-4a18-4dca-a896-e2fc86746015 >> >> [workload] >> rw=randread >> bssplit=1k/50:128k/50 > > > What's causing this issue is the use of the 64-bit random generator. > There's a bug in the bssplit calculation code that overflows for that > case. I've pushed a fix out for it: > > http://git.kernel.dk/cgit/fio/commit/?id=3dd29f7c21538c164fcbd078c3f2e532a9193a04 > > With that fix, you should see better behavior. Note that to truly have a > 50/50 split for this, you'd want to set 'norandommap' as well. Otherwise > fio will fit the block size to avoid overlapped IO. When that happens, > you'll have 50% 1k random reads, but the other 50% will be between 1k > and 128k. If a 128k random read would overlap at the generated offset, > fio would adjust it down. > > -- > Jens Axboe > -- 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
