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
