Re: [PATCH 1/2] Added replay_rebase option to run multi-threaded log replay on different disk sectors.

[Taisuke Yamada <tai@xxxxxxxxxxxx>]

> 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