(CCing Jens) On 27 March 2018 at 16:23, Kris Davis <Kris.Davis@xxxxxxx> wrote: > Sitsofe, > > I'm wondering if I've completely misunderstood the meaning of "looping". I was thinking it basically meant to "repeat" the job specification a number of times, but from your description of the impacts, that appears to be wrong. > > Looking at other verbiage in the doc, "loops" say to "repeat same workload a given number of times". Under time_based, it says "it will simply loop over the same workload as many times as runtime allows". I'm wondering if the word 'loop' is really means the same thing in these two descriptions. If nothing is really "reset" between loop iterations, then it seems to me that these two uses of 'loop' mean the same thing. > > Sorry if I'm missing the point, but if the "loops" option really doesn't effect other aspects like the runtime, ramp_time or resetting LBAs and such, I'm confused when "loops" would be used - what does it accomplish that isn't available through other options? > > Thanks > > Kris Davis > > -----Original Message----- > From: Sitsofe Wheeler [mailto:sitsofe@xxxxxxxxx] > Sent: Monday, March 26, 2018 2:52 PM > To: Kris Davis <Kris.Davis@xxxxxxx> > Cc: fio@xxxxxxxxxxxxxxx; Itay Ben Yaacov <Itay.BenYaacov@xxxxxxx> > Subject: Re: "No I/O performed by <engine>" reporting bug? > > On 26 March 2018 at 18:40, Kris Davis <Kris.Davis@xxxxxxx> wrote: >> >> I guess I'm was expecting that loops just means to repeat whatever the job was doing previously that number of times. I guess that what I conclude from the "loops" description: "Run the specified number of iterations of this job. Used to repeat the same workload a given number of times. Defaults to 1." >> >> I was expecting that each loop would start sequential operations back >> at 0 or the offset, and redo any start_delay or ramp_time each time. >> If that is not the case, I'm > > loops looks like a way to get a job to wrap I/O around to beginning it when it gets to the end of the file. Certain operations do happen when that wraparound/restart occurs (e.g. resetting the map of regions used/offset being reset on sequential I/O) but not every job option is impacted (i.e. start_delay and ramp_time will only happen once even when loops>=2). > >> either missing something in the doc, or it could probably use further clarification. If io_size is used rather than number_ios - does the starting LBA get reset after each loop? > > Looking at some examples I see this: > > $ ./fio --name=test-loops --filename=/tmp/fio.tmp --size=4 --bs=1 > --loops=2 --io_size=3 --debug=io | grep 'complete:\|cache' > io 7649 declare unneeded cache /tmp/fio.tmp: 0/4 > io 7649 complete: io_u 0xb78500: off=0x0,len=0x1,ddir=0,file=/tmp/fio.tmp > io 7649 complete: io_u 0xb78500: off=0x1,len=0x1,ddir=0,file=/tmp/fio.tmp > io 7649 complete: io_u 0xb78500: off=0x2,len=0x1,ddir=0,file=/tmp/fio.tmp > io 7649 complete: io_u 0xb78500: off=0x3,len=0x1,ddir=0,file=/tmp/fio.tmp > io 7649 declare unneeded cache /tmp/fio.tmp: 0/4 > io 7649 complete: io_u 0xb78500: off=0x0,len=0x1,ddir=0,file=/tmp/fio.tmp > io 7649 complete: io_u 0xb78500: off=0x1,len=0x1,ddir=0,file=/tmp/fio.tmp > > $ $ ./fio --name=test-loops --filename=/tmp/fio.tmp --size=4 --bs=1 > --loops=3 --number_ios=2 --debug=io | grep 'complete:\|cache' > io 7657 declare unneeded cache /tmp/fio.tmp: 0/4 > io 7657 complete: io_u 0x2310500: > off=0x0,len=0x1,ddir=0,file=/tmp/fio.tmp > io 7657 complete: io_u 0x2310500: > off=0x1,len=0x1,ddir=0,file=/tmp/fio.tmp > io 7657 complete: io_u 0x2310500: > off=0x2,len=0x1,ddir=0,file=/tmp/fio.tmp > io 7657 complete: io_u 0x2310500: > off=0x3,len=0x1,ddir=0,file=/tmp/fio.tmp > io 7657 declare unneeded cache /tmp/fio.tmp: 0/4 > io 7657 complete: io_u 0x2310500: > off=0x0,len=0x1,ddir=0,file=/tmp/fio.tmp > io 7657 complete: io_u 0x2310500: > off=0x1,len=0x1,ddir=0,file=/tmp/fio.tmp > > Basically a loop only ends when I/O gets to the end of the file (and we see the cache being declared unneeded when the loop starts) but the interaction with number_ios/io_size seems limited to just multiplying them by loops. > > Jens: originally number_ios/io_size would just end the entire job early regardless of what loop you were on but that seems to have changed since cf8a46a75f38afe07ebf823210f95543999e3116 ("Make 'loops' > honor full write+verify loops"). Is the intent for number_ios/io_size to be invariant of loops or to be per loop? What does it mean for a loop if io_size is bigger than the size of the file? > >> I don't really have any strong opinion on how number_ios works (we can use io_size instead), it just seems like it was working differently before, and otherwise could just use further clarification. Do you know of any other "quantity" type of options would operate independent of the loops option? (I think this is the first time I've seen loop used). > > runtime is the other one (we've covered io_size, number_ios and loops) and that's loop invariant. In fact runtime with time_based essentially disables looking at the loop counter. -- Sitsofe | http://sucs.org/~sits/ -- 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
