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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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


[Home]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Video Projectors]     [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]

Powered by Linux