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
