On 28/07/14 20:35, Carl Zwanzig wrote:
Hi,
For the most part, I've stopped using job files and use a script to write/execute a fio command line. I do end up with hideously-long command lines (>1100 chars), but can stash all the parameters in the script or included file and easily iterate over certain ones.
We went a similar way, but not that far to push all into the commandline.
The reason for that is that I liked the job file format, it was easy to
grasp for everyone - and eventually I have jobfiles I can pass along if
I identify a bug.
So what I ended up was having a few basic profiles (for totally
different fio job behaviour) and filling a lot of things via environment
variables that are set by a wrapper script.
In my opinion that gives you the flexibility to iterate like Carl
suggested in his solution while keeping the majority of the jobfile
semantic.
For example our global section often is only something like this:
[global]
bs=${FIO_BS}
[...]
And you can even add non-predefined options with a trick like this:
${FIO_FREEPARM1}
[...]
Just make the variable contain the full specification like "numjobs=4"
and it will work. In case you don't use those I usually set
description=n/a to all of them to avoid bugs due to unset variables.
I hope one of the suggestions helps you,
Christian
--
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
