Ah, I finally got what "group" means here. Ignore last mail. On Sat, Sep 29, 2012 at 1:08 AM, Akash Verma <akashv@xxxxxxxxxx> wrote: > Thanks Jens. So now with my new understanding of things, my > expectation is that running FIO with a job file like this: > > [job_1] > rw=randwrite > size=1024k > ioengine=libaio > time_based=1 > runtime=10 > direct=1 > do_verify=0 > > [job_2] > rw=randread > size=1024k > ioengine=libaio > time_based=1 > runtime=10 > direct=1 > > It's the same reporting group, so I expect a single output. However I > actually get one output each. Is this a bug? - or do I need to go get > some sleep and look at the whole thing again tomorrow :-| > > Thanks, > Akash > > On Sat, Sep 29, 2012 at 12:59 AM, Jens Axboe <axboe@xxxxxxxxx> wrote: >> On 2012-09-29 09:32, Akash Verma wrote: >>> That's odd, because I understood it differently. I have gone through >>> the HOWTO again to be sure. Please bear with me; I'm copying >>> succeeding lines from the HOWTO from version 2.0.9: >>> >>> new_groupStart a new reporting group. If this option isn't given, >>> jobs in a file will be part of the same reporting group >>> unless separated by a stone wall (or if it's a group >>> by itself, with the numjobs option). >>> >>> numjobs=intCreate the specified number of clones of this job. May be >>> used to setup a larger number of threads/processes doing >>> the same thing. We regard that grouping of jobs as a >>> specific group. >>> >>> group_reportingIf 'numjobs' is set, it may be interesting to display >>> statistics for the group as a whole instead of for each >>> individual job. This is especially true of 'numjobs' is >>> large, looking at individual thread/process output quickly >>> becomes unwieldy. If 'group_reporting' is specified, fio >>> will show the final report per-group instead of per-job. >>> >>> Is it just me? Reading that, I don't see any confusion about the >>> group_reporting flag being specifically for clumping together results >>> that would otherwise be discrete for each job clone because of >>> numjobs. >>> >>> Even here, the description for new_group implies that jobs in a job >>> file are in the same reporting group, unless <condition 1> and >>> <condition 2>. But it seems to be the default behavior to not have >>> them in the same reporting group. For example, I used the file >>> included in the first email, but without numjobs and group_reporting. >>> Then I get one report for each job. >>> >>> In my opinion, the current functionality is fine, but the >>> documentation isn't clear on it. >> >> OK, I see what you mean wrt numjobs=. It is implied that this >> constitutes a group of its own, which it doesn't. I agree that the >> current behavior is fine, in fact it'd be a bother if numjobs= did imply >> a new group. I'll get the documentation updated for that specific case >> soon - or I'll take a patch as well, of course :-) >> >> -- >> 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
