Re: An alternative way to handle IO engine options

[Jens Axboe <axboe@xxxxxxxxx>]

On 2011-11-02 01:27, Steven Lang wrote:
> Alright I'll go ahead with finishing it.
> 
> For the issue of global options...  There are two possibilities I have
> in mind.  The first is to limit it to just an ioengine that is
> specified, and the options for that ioengine are the only ioengine
> options that are allowed.  That would probably be "good enough" for
> most cases.  However, for a load which used two different IO engines,
> it would limit the global options to only one of the ioengines.
> 
> The second option would be to have a way to specify options for
> different ioengines within the global section, then keep a copy of the
> config struct for each that is specified to use as a template.
> 
> What I don't like about the second option is that the conf syntax for
> it might be somewhat messy.
> 
> A third option would be to just parse the global options with respect
> to every known ioengine, or even just store the raw config values and
> parse them with each job.
> 
> I'm not sure which is the best option; however unless there's some
> justification for doing otherwise I may just go with the first
> (simplest) for now, and if it becomes an issue the rest can be patched
> in later.

That sounds like a reasonable approach, we need not over-design it.

-- 
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