On 2012-08-07 13:32 Shaohua Li <shli@xxxxxxxxxx> Wrote:
>2012/8/7 Jianpeng Ma <majianpeng@xxxxxxxxx>:
>> On 2012-08-07 11:22 Shaohua Li <shli@xxxxxxxxxx> Wrote:
>>>My directIO randomwrite 4k workload shows a 10~20% regression caused by commit
>>>895e3c5c58a80bb. directIO usually is random IO and if request size isn't big
>>>(which is the common case), delay handling of the stripe hasn't any advantages.
>>>For big size request, delay can still reduce IO.
>>>
>>>Signed-off-by: Shaohua Li <shli@xxxxxxxxxxxx>
>>>---
>>> drivers/md/raid5.c | 9 ++++++++-
>>> 1 file changed, 8 insertions(+), 1 deletion(-)
[snip]
>>>--
>> May be used size to judge is not a good method.
>> I firstly sended this patch, only want to control direct-write-block,not for reqular file.
>> Because i think if someone used direct-write-block for raid5,he should know the feature of raid5 and he can control
>> for write to full-write.
>> But at that time, i did know how to differentiate between regular file and block-device.
>> I thik we should do something to do this.
>
>I don't think it's possible user can control his write to be a
>full-write even for
>raw disk IO. Why regular file and block device io matters here?
>
>Thanks,
>Shaohua
The problem is when to set flag STRIPE_PREREAD_ACTIVE.
When setting this flag, it will to handle stripe instead of delaying for full-write.
I think it like the IOPS and throughput.
When in random-small-write workload, it't hardly to achieve full-write.So no need to dealy.This like sync-write.
But for larger-write workload, it's easly to achieve full-write.
This is why send the path. My workload is the latter.
For regular file, it controled by fs.But for raw-block,i think we do the work by fs, so we can control to do the best performance.
Of cource, My work is do this,so my point may be limited.?韬{.n?????%??檩??w?{.n???{炳盯w???塄}?财??j:+v?? ? ???2??璀??摺?囤??z夸z罐?+?????w棹f
