> On patch 1, I don't know, it seems a bit weird to me. The fact that the > option offset is multiplied by the job number makes sense for ease of > handling job files (since you can just do numjobs=X and be done with > it), but logically it's odd since you have to know that they are > numbered sequentially and do the math to see where it ends up on the > disk. > > What is the intended use case for this? I'd much rather see the offset > be absolute, at the cost of a bit more complex job file. My intention (and usecase) is just to put more replay I/O load, so multiplication is purely for ease of use. So yes, I can live perfectly fine with per-thread(job) absolute offset configuration. In fact, it may be better as offset can be chosen to access disk more evenly/randomly. Do you want me to submit a new patch without multiplication? -- 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
