Flexible I/O Tester development
 help / color / mirror / Atom feed
From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
To: Carl Zwanzig <cpz@coraid.com>,
	"fio@vger.kernel.org" <fio@vger.kernel.org>
Subject: Re: Pull an external [global] section into an .fio file?
Date: Tue, 29 Jul 2014 07:28:16 +0200	[thread overview]
Message-ID: <53D730F0.3030908@linux.vnet.ibm.com> (raw)
In-Reply-To: <A7A1D348E34E024BBC74480FB93A2EAB108B4DB1@DAGN05C-E6.exg6.exghost.com>

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


  reply	other threads:[~2014-07-29  5:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-28 17:42 Pull an external [global] section into an .fio file? Andrey Kuzmin
2014-07-28 18:21 ` Kulkarni, Vasu
2014-07-28 18:35   ` Carl Zwanzig
2014-07-29  5:28     ` Christian Ehrhardt [this message]
2014-07-29  6:47 ` Jens Axboe
2014-07-29 17:30   ` Andrey Kuzmin
2014-07-30 12:25     ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53D730F0.3030908@linux.vnet.ibm.com \
    --to=ehrhardt@linux.vnet.ibm.com \
    --cc=cpz@coraid.com \
    --cc=fio@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox