On Fri, Apr 04 2014, Carl Zwanzig wrote:
> Hello,
>
> This has been bugging me for a while... it appears that we have a
> choice of using either cmd line parameters xor a job file (but not
> combining the two) to fully specify a job.
>
> For instance:
> fio --runtime=20 derf.cfg
> fio: time_based requires a runtime/timeout setting
> file__0: (g=0): rw=read, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=32
> fio-2.1.6.1
> [...]
> where derf.cfg starts otherwise fully specified the job, just doesn't
> have the runtime.
>
> There are ways around this for some cases by using environment
> variables (e.g. "RT=20 fio def.cfg" and runtime=${RT}) but those can
> get clunky and only allows value substitutions, not additional
> directives. In my current case, I'd like to have the config file
> supply default values for certain parameters and override them as
> needed from the command line (e.g. runtime=20 unless I say otherwise).
> Right now, I already have 6 or 7 env vars passed in to the job file
> and that's too many.
>
> Is there any way to do this without really hacking up the parsing
> code? I'm currently looking at init.c, where it looks like the cmd
> line is parsed first then the job file(s), but I lose the mental
> thread when I get into parse_jobs_ini(). Ideally, any fio options on
> the command line before a --name= would be stuck at the end of the
> global thread data (*td_parent?), similar to including a directive
> multiple times.
Should be fairly easy to fix - right now the transition would imply a
job barrier, which is why it doesn't work. We could just assume [global]
state for that.
--
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
