FIO size parameter feedback

FIO size parameter feedback

[abhishek koundal]

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?

Reason I am asking as I see different data for the same workloads when
size=100% and no size parameter used.

-- 
Life is too short for silly things so invest your time in some
productive outputs!!

Re: FIO size parameter feedback

[Sitsofe Wheeler]

Hi,

On 6 March 2018 at 18:52, abhishek koundal <akoundal@gmail.com> 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?

-- 
Sitsofe | http://sucs.org/~sits/

Re: FIO size parameter feedback

[Sitsofe Wheeler]

On 6 March 2018 at 19:02, Sitsofe Wheeler <sitsofe@gmail.com> wrote:
> Hi,
>
> On 6 March 2018 at 18:52, abhishek koundal <akoundal@gmail.com> 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/

Re: FIO size parameter feedback

[abhishek koundal]

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@gmail.com> 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@gmail.com> wrote:
>>
>> On 6 March 2018 at 19:02, Sitsofe Wheeler <sitsofe@gmail.com> wrote:
>> > Hi,
>> >
>> > On 6 March 2018 at 18:52, abhishek koundal <akoundal@gmail.com> 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!!

Re: FIO size parameter feedback

[abhishek koundal]

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@gmail.com> 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@gmail.com> 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@gmail.com> wrote:
>>>
>>> On 6 March 2018 at 19:02, Sitsofe Wheeler <sitsofe@gmail.com> wrote:
>>> > Hi,
>>> >
>>> > On 6 March 2018 at 18:52, abhishek koundal <akoundal@gmail.com> 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!!



-- 
Life is too short for silly things so invest your time in some
productive outputs!!

Re: FIO size parameter feedback

[Sitsofe Wheeler]

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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com> wrote:
>>>>
>>>> On 6 March 2018 at 19:02, Sitsofe Wheeler <sitsofe@gmail.com> wrote:
>>>> > Hi,
>>>> >
>>>> > On 6 March 2018 at 18:52, abhishek koundal <akoundal@gmail.com> 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/

Re: FIO size parameter feedback

[abhishek koundal]

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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com> wrote:
>>>>>
>>>>> On 6 March 2018 at 19:02, Sitsofe Wheeler <sitsofe@gmail.com> wrote:
>>>>> > Hi,
>>>>> >
>>>>> > On 6 March 2018 at 18:52, abhishek koundal <akoundal@gmail.com> 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!!

Re: FIO size parameter feedback

[Sitsofe Wheeler]

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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com> wrote:
>>>>>>>
>>>>>>> On 6 March 2018 at 19:02, Sitsofe Wheeler <sitsofe@gmail.com> wrote:
>>>>>>> > Hi,
>>>>>>> >
>>>>>>> > On 6 March 2018 at 18:52, abhishek koundal <akoundal@gmail.com> 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/

Re: FIO size parameter feedback

[abhishek koundal]

Hi
Yes that is correct. The drive is showing :
2000398934016 and its not exact multiple of 128K

So do we think this is how the tool will behave or we have a bug here?

On Wed, Mar 7, 2018 at 12:17 AM, Sitsofe Wheeler <sitsofe@gmail.com> wrote:
> 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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com> wrote:
>>>>>>>>
>>>>>>>> On 6 March 2018 at 19:02, Sitsofe Wheeler <sitsofe@gmail.com> wrote:
>>>>>>>> > Hi,
>>>>>>>> >
>>>>>>>> > On 6 March 2018 at 18:52, abhishek koundal <akoundal@gmail.com> 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/



-- 
Life is too short for silly things so invest your time in some
productive outputs!!

Re: FIO size parameter feedback

[Sitsofe Wheeler]

I'd say it's something that could be better documented (size as
percentage rounds to the minimum blocksize) in the same way it's
already documented for offset percentages. The problem is if size
didn't do the rounding of percentages things would get tricky when you
start trying to cut disks up using offset and size (think offset=0%
size=25% then offset=25% size=25%). Plus you don't really want to do
rounding when the user specifies an exact amount/doesn't set anything
at all because you want to assume the user knows what they are
doing...

On 7 March 2018 at 18:14, abhishek koundal <akoundal@gmail.com> wrote:
> Hi
> Yes that is correct. The drive is showing :
> 2000398934016 and its not exact multiple of 128K
>
> So do we think this is how the tool will behave or we have a bug here?
>
> On Wed, Mar 7, 2018 at 12:17 AM, Sitsofe Wheeler <sitsofe@gmail.com> wrote:
>> 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...

-- 
Sitsofe | http://sucs.org/~sits/

Re: FIO size parameter feedback

[abhishek koundal]

So do we say its how the tool has to behave? (surely with added documentation)

On Wed, Mar 7, 2018 at 10:38 AM, Sitsofe Wheeler <sitsofe@gmail.com> wrote:
> I'd say it's something that could be better documented (size as
> percentage rounds to the minimum blocksize) in the same way it's
> already documented for offset percentages. The problem is if size
> didn't do the rounding of percentages things would get tricky when you
> start trying to cut disks up using offset and size (think offset=0%
> size=25% then offset=25% size=25%). Plus you don't really want to do
> rounding when the user specifies an exact amount/doesn't set anything
> at all because you want to assume the user knows what they are
> doing...
>
> On 7 March 2018 at 18:14, abhishek koundal <akoundal@gmail.com> wrote:
>> Hi
>> Yes that is correct. The drive is showing :
>> 2000398934016 and its not exact multiple of 128K
>>
>> So do we think this is how the tool will behave or we have a bug here?
>>
>> On Wed, Mar 7, 2018 at 12:17 AM, Sitsofe Wheeler <sitsofe@gmail.com> wrote:
>>> 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...
>
> --
> Sitsofe | http://sucs.org/~sits/



-- 
Life is too short for silly things so invest your time in some
productive outputs!!

Re: FIO size parameter feedback

[Sitsofe Wheeler]

I'd argue that by now someone will have started depending on the
rounding behaviour of a percentage size and someone else will be
depending on the non-rounding behaviour when its specified without
percentages so you'd need a strong reason to change. However
documenting this quirk would be helpful...

On 7 March 2018 at 19:07, abhishek koundal <akoundal@gmail.com> wrote:
> So do we say its how the tool has to behave? (surely with added documentation)
>
> On Wed, Mar 7, 2018 at 10:38 AM, Sitsofe Wheeler <sitsofe@gmail.com> wrote:
>> I'd say it's something that could be better documented (size as
>> percentage rounds to the minimum blocksize) in the same way it's
>> already documented for offset percentages. The problem is if size
>> didn't do the rounding of percentages things would get tricky when you
>> start trying to cut disks up using offset and size (think offset=0%
>> size=25% then offset=25% size=25%). Plus you don't really want to do
>> rounding when the user specifies an exact amount/doesn't set anything
>> at all because you want to assume the user knows what they are
>> doing...

-- 
Sitsofe | http://sucs.org/~sits/

Re: FIO size parameter feedback

[Jens Axboe]

I think we should just skip the alignment/adjustment if
size_percent is equal to 100. It doesn't make sense to
change it for full size. I'd rather have consistent
behavior here, and I think the risk is pretty low in
this case.

On 3/7/18 1:19 PM, Sitsofe Wheeler wrote:
> I'd argue that by now someone will have started depending on the
> rounding behaviour of a percentage size and someone else will be
> depending on the non-rounding behaviour when its specified without
> percentages so you'd need a strong reason to change. However
> documenting this quirk would be helpful...
> 
> On 7 March 2018 at 19:07, abhishek koundal <akoundal@gmail.com> wrote:
>> So do we say its how the tool has to behave? (surely with added documentation)
>>
>> On Wed, Mar 7, 2018 at 10:38 AM, Sitsofe Wheeler <sitsofe@gmail.com> wrote:
>>> I'd say it's something that could be better documented (size as
>>> percentage rounds to the minimum blocksize) in the same way it's
>>> already documented for offset percentages. The problem is if size
>>> didn't do the rounding of percentages things would get tricky when you
>>> start trying to cut disks up using offset and size (think offset=0%
>>> size=25% then offset=25% size=25%). Plus you don't really want to do
>>> rounding when the user specifies an exact amount/doesn't set anything
>>> at all because you want to assume the user knows what they are
>>> doing...
> 


-- 
Jens Axboe

Re: FIO size parameter feedback

[abhishek koundal]

Are we suggesting the document wording change or actual code change?

On Fri, Mar 9, 2018 at 11:54 AM, Jens Axboe <axboe@kernel.dk> wrote:
> I think we should just skip the alignment/adjustment if
> size_percent is equal to 100. It doesn't make sense to
> change it for full size. I'd rather have consistent
> behavior here, and I think the risk is pretty low in
> this case.
>
> On 3/7/18 1:19 PM, Sitsofe Wheeler wrote:
>> I'd argue that by now someone will have started depending on the
>> rounding behaviour of a percentage size and someone else will be
>> depending on the non-rounding behaviour when its specified without
>> percentages so you'd need a strong reason to change. However
>> documenting this quirk would be helpful...
>>
>> On 7 March 2018 at 19:07, abhishek koundal <akoundal@gmail.com> wrote:
>>> So do we say its how the tool has to behave? (surely with added documentation)
>>>
>>> On Wed, Mar 7, 2018 at 10:38 AM, Sitsofe Wheeler <sitsofe@gmail.com> wrote:
>>>> I'd say it's something that could be better documented (size as
>>>> percentage rounds to the minimum blocksize) in the same way it's
>>>> already documented for offset percentages. The problem is if size
>>>> didn't do the rounding of percentages things would get tricky when you
>>>> start trying to cut disks up using offset and size (think offset=0%
>>>> size=25% then offset=25% size=25%). Plus you don't really want to do
>>>> rounding when the user specifies an exact amount/doesn't set anything
>>>> at all because you want to assume the user knows what they are
>>>> doing...
>>
>
>
> --
> Jens Axboe
>



-- 
Life is too short for silly things so invest your time in some
productive outputs!!

Re: FIO size parameter feedback

[Jens Axboe]

Code change, I don't think it makes any sense that 100% behaves
differently than not setting it at all, since that's equivalent
to 100%.

Already made the change...

On 3/9/18 1:08 PM, abhishek koundal wrote:
> Are we suggesting the document wording change or actual code change?
> 
> On Fri, Mar 9, 2018 at 11:54 AM, Jens Axboe <axboe@kernel.dk> wrote:
>> I think we should just skip the alignment/adjustment if
>> size_percent is equal to 100. It doesn't make sense to
>> change it for full size. I'd rather have consistent
>> behavior here, and I think the risk is pretty low in
>> this case.
>>
>> On 3/7/18 1:19 PM, Sitsofe Wheeler wrote:
>>> I'd argue that by now someone will have started depending on the
>>> rounding behaviour of a percentage size and someone else will be
>>> depending on the non-rounding behaviour when its specified without
>>> percentages so you'd need a strong reason to change. However
>>> documenting this quirk would be helpful...
>>>
>>> On 7 March 2018 at 19:07, abhishek koundal <akoundal@gmail.com> wrote:
>>>> So do we say its how the tool has to behave? (surely with added documentation)
>>>>
>>>> On Wed, Mar 7, 2018 at 10:38 AM, Sitsofe Wheeler <sitsofe@gmail.com> wrote:
>>>>> I'd say it's something that could be better documented (size as
>>>>> percentage rounds to the minimum blocksize) in the same way it's
>>>>> already documented for offset percentages. The problem is if size
>>>>> didn't do the rounding of percentages things would get tricky when you
>>>>> start trying to cut disks up using offset and size (think offset=0%
>>>>> size=25% then offset=25% size=25%). Plus you don't really want to do
>>>>> rounding when the user specifies an exact amount/doesn't set anything
>>>>> at all because you want to assume the user knows what they are
>>>>> doing...
>>>
>>
>>
>> --
>> Jens Axboe
>>
> 
> 
> 


-- 
Jens Axboe

Re: FIO size parameter feedback

[abhishek koundal]

[-- Attachment #1: Type: text/plain, Size: 2050 bytes --]

Cool, thanks!

On Mar 9, 2018 12:32 PM, "Jens Axboe" <axboe@kernel.dk> wrote:

> Code change, I don't think it makes any sense that 100% behaves
> differently than not setting it at all, since that's equivalent
> to 100%.
>
> Already made the change...
>
> On 3/9/18 1:08 PM, abhishek koundal wrote:
> > Are we suggesting the document wording change or actual code change?
> >
> > On Fri, Mar 9, 2018 at 11:54 AM, Jens Axboe <axboe@kernel.dk> wrote:
> >> I think we should just skip the alignment/adjustment if
> >> size_percent is equal to 100. It doesn't make sense to
> >> change it for full size. I'd rather have consistent
> >> behavior here, and I think the risk is pretty low in
> >> this case.
> >>
> >> On 3/7/18 1:19 PM, Sitsofe Wheeler wrote:
> >>> I'd argue that by now someone will have started depending on the
> >>> rounding behaviour of a percentage size and someone else will be
> >>> depending on the non-rounding behaviour when its specified without
> >>> percentages so you'd need a strong reason to change. However
> >>> documenting this quirk would be helpful...
> >>>
> >>> On 7 March 2018 at 19:07, abhishek koundal <akoundal@gmail.com> wrote:
> >>>> So do we say its how the tool has to behave? (surely with added
> documentation)
> >>>>
> >>>> On Wed, Mar 7, 2018 at 10:38 AM, Sitsofe Wheeler <sitsofe@gmail.com>
> wrote:
> >>>>> I'd say it's something that could be better documented (size as
> >>>>> percentage rounds to the minimum blocksize) in the same way it's
> >>>>> already documented for offset percentages. The problem is if size
> >>>>> didn't do the rounding of percentages things would get tricky when
> you
> >>>>> start trying to cut disks up using offset and size (think offset=0%
> >>>>> size=25% then offset=25% size=25%). Plus you don't really want to do
> >>>>> rounding when the user specifies an exact amount/doesn't set anything
> >>>>> at all because you want to assume the user knows what they are
> >>>>> doing...
> >>>
> >>
> >>
> >> --
> >> Jens Axboe
> >>
> >
> >
> >
>
>
> --
> Jens Axboe
>
>

[-- Attachment #2: Type: text/html, Size: 2991 bytes --]

Re: FIO size parameter feedback

[abhishek koundal]

Thanks

On Fri, Mar 9, 2018 at 12:32 PM, Jens Axboe <axboe@kernel.dk> wrote:
> Code change, I don't think it makes any sense that 100% behaves
> differently than not setting it at all, since that's equivalent
> to 100%.
>
> Already made the change...
>
> On 3/9/18 1:08 PM, abhishek koundal wrote:
>> Are we suggesting the document wording change or actual code change?
>>
>> On Fri, Mar 9, 2018 at 11:54 AM, Jens Axboe <axboe@kernel.dk> wrote:
>>> I think we should just skip the alignment/adjustment if
>>> size_percent is equal to 100. It doesn't make sense to
>>> change it for full size. I'd rather have consistent
>>> behavior here, and I think the risk is pretty low in
>>> this case.
>>>
>>> On 3/7/18 1:19 PM, Sitsofe Wheeler wrote:
>>>> I'd argue that by now someone will have started depending on the
>>>> rounding behaviour of a percentage size and someone else will be
>>>> depending on the non-rounding behaviour when its specified without
>>>> percentages so you'd need a strong reason to change. However
>>>> documenting this quirk would be helpful...
>>>>
>>>> On 7 March 2018 at 19:07, abhishek koundal <akoundal@gmail.com> wrote:
>>>>> So do we say its how the tool has to behave? (surely with added documentation)
>>>>>
>>>>> On Wed, Mar 7, 2018 at 10:38 AM, Sitsofe Wheeler <sitsofe@gmail.com> wrote:
>>>>>> I'd say it's something that could be better documented (size as
>>>>>> percentage rounds to the minimum blocksize) in the same way it's
>>>>>> already documented for offset percentages. The problem is if size
>>>>>> didn't do the rounding of percentages things would get tricky when you
>>>>>> start trying to cut disks up using offset and size (think offset=0%
>>>>>> size=25% then offset=25% size=25%). Plus you don't really want to do
>>>>>> rounding when the user specifies an exact amount/doesn't set anything
>>>>>> at all because you want to assume the user knows what they are
>>>>>> doing...
>>>>
>>>
>>>
>>> --
>>> Jens Axboe
>>>
>>
>>
>>
>
>
> --
> Jens Axboe
>



-- 
Life is too short for silly things so invest your time in some
productive outputs!!