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

[Jens Axboe <axboe@kernel.dk>]

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