Hi, What does blockdev --getsize64 /dev/nvme0n1 say? I'm going to guess that whatever number comes out is not an exact multiple of 128Kbytes... On 7 March 2018 at 00:58, abhishek koundal <akoundal@xxxxxxxxx> wrote: > Sitsofe, > here is the log file when the size parameter is not give. > command line will be : > fio --name=global --time_based --direct=1 --norandommap > --randrepeat=0 --buffered=0 --refill_buffers --name=job > --ioengine=libaio --group_reporting --filename=/dev/nvme0n1 > --numjobs=1 --iodepth=128 --bs=128k --rw=rw --rwmixread=70 > --runtime=10800 --write_iops_log=wr.log -write_lat_log=wr.clat.log > --log_avg_msec=1000 > > On Tue, Mar 6, 2018 at 2:28 PM, abhishek koundal <akoundal@xxxxxxxxx> wrote: >> Sure Sitsofe >> fio --name=global --time_based --size=100% --direct=1 --norandommap >> --randrepeat=0 --buffered=0 --refill_buffers --name=job >> --ioengine=libaio --group_reporting --filename=/dev/nvme0n1 >> --numjobs=1 --iodepth=128 --bs=128k --rw=rw --rwmixread=70 >> --runtime=10800 --write_iops_log=wr.log -write_lat_log=wr.clat.log >> --log_avg_msec=1000 >> >> On Tue, Mar 6, 2018 at 1:23 PM, Sitsofe Wheeler <sitsofe@xxxxxxxxx> wrote: >>> An example of an engine that can't deduce a size by itself is the null >>> engine. Most file based engines (e.g. pvsync, sync, libaio) are able >>> to. >>> >>> I'd really have to see the exact jobs that were run (i.e. the complete >>> command line and fio job file if there was one) and the exact output >>> that you mention showed the problem to say more. For example you say >>> 2TBytes but that's probably not granular enough. What is more >>> interesting is the size of the disk in bytes (from Linux's >>> perspective) because I'd need to know exactly what rounding occured to >>> understand what happened. >>> >>> On 6 March 2018 at 20:28, abhishek koundal <akoundal@xxxxxxxxx> wrote: >>>> Sitsofe >>>> The engine used is the libaio. I hope this helps. >>>> Can you elaborate on the ioengine part which are able to query the >>>> file/disk size and which wont be able to ? (I generally use libaio for >>>> QD>1) >>>> >>>> On Tue, Mar 6, 2018 at 11:47 AM, abhishek koundal <akoundal@xxxxxxxxx> wrote: >>>>> Hi, >>>>> The workload I used was SEQ_MX 70/30 BS 128 QD 128 >>>>> FIO used 3.1 >>>>> Drive SKU = 2TB >>>>> >>>>> On Tue, Mar 6, 2018 at 11:43 AM, abhishek koundal <akoundal@xxxxxxxxx> wrote: >>>>>> Hi, >>>>>> The workload I used was SEQ_MX 70/30 BS 128 QD 128 >>>>>> FIO used 3.1 >>>>>> >>>>>> On Tue, Mar 6, 2018 at 11:11 AM, Sitsofe Wheeler <sitsofe@xxxxxxxxx> wrote: >>>>>>> >>>>>>> On 6 March 2018 at 19:02, Sitsofe Wheeler <sitsofe@xxxxxxxxx> wrote: >>>>>>> > Hi, >>>>>>> > >>>>>>> > On 6 March 2018 at 18:52, abhishek koundal <akoundal@xxxxxxxxx> wrote: >>>>>>> >> All >>>>>>> >> If the size parameter is not given for the runs, how does the tool >>>>>>> >> decide what % (LBA span) needs to be written on the drive? >>>>>>> > >>>>>>> > It will query the disk/file for its size (but this depends on the >>>>>>> > ioengine being able to do that and not all do/can). >>>>>>> > >>>>>>> >> Reason I am asking as I see different data for the same workloads when >>>>>>> >> size=100% and no size parameter used. >>>>>>> > >>>>>>> > Hmm this sounds like it might be due to a rounding issue - what size >>>>>>> > is your disk and what job were you running? >>>>>>> >>>>>>> https://github.com/axboe/fio/blob/master/filesetup.c#L1039-L1048 shows >>>>>>> that when in setup_files() using a size set in percent will round the >>>>>>> io_size down to the minimum block size whereas not setting size at all >>>>>>> looks like it will pass the determined size straight through >>>>>>> unrounded. I'm not sure what job you would see the difference on - >>>>>>> perhaps one that did backwards I/O? >>> >>> -- >>> Sitsofe | http://sucs.org/~sits/ >> >> >> >> -- >> Life is too short for silly things so invest your time in some >> productive outputs!! > > > > -- > Life is too short for silly things so invest your time in some > productive outputs!! -- 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
