On 2011-09-15 13:40, Taisuke Yamada wrote: >> 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? Yeah, please do one without the multiplier and I guess we can put it in. -- 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
