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
