Re: [PATCH 5/5] Add option to specify ramp period by amount of IO

[Damien Le Moal <dlemoal@kernel.org>]

On 12/19/25 01:31, Jan Kara wrote:
>>> +.. option:: ramp_size=size
>>> +
>>> +	If set, fio will wait until the workload does given amount of IO before
>>> +	logging any performance numbers. Similar considerations apply as for
>>> +	``ramp_time`` option. When the unit is omitted, the value is given in
>>> +	megabytes.
>>
>> Hmm... It may be less confusing/easier to use the regular fio "int" parameter
>> type here, which takes all the kilo, mega etc suffixes. This means that the
>> default without any suffix would be bytes, not megabytes.
> 
> Well, this argument also takes all the kilo, mega, etc. suffixes. Just
> without any suffix it will default to MB. I've copied this behavior from
> 'size' and 'filesize' options which behave like this striving for some
> consistency. That being said I don't really care deeply about the behavior
> without units because I think sane people write the units explicitly.

Sam here: I do not really mind one way or the other. I raised this comment so
that the options stay consistent in behavior, same as you aim for.

Checking with some quick runs, if I run something like:

fio --name=write --ioengine=psync --bs=512 --rw=write --directory=/mnt \
	--filename_format='test.$jobnum.$filenum' --nrfiles=16 --openfiles=1 \
	--create_fsync=0 --filesize=1024 --create_on_open=1 \
	--allow_file_create=1 --end_fsync=1

I get files of 1024B, not 1GiB. Same with even smaller values like:
	--bs=8 --filesize=8
I get files of 8 Bytes.

So I doubt that the default is MiB when there is no unit specified.

Checking the code, the .interval field of filesize option (and all other options
in fact) seems to be unused, except by the goptions.c file, which I think is for
the fio GUI.

So the default it seems is Bytes when no unit suffix is specified. Your code is
good then, except the man page and HOWTO files where you should remove the text
"When the unit is omitted, the value is given in megabytes."

With that,

Reviewed-by: Damien Le Moal <dlemoal@kernel.org>

-- 
Damien Le Moal
Western Digital Research