On 8/25/20 3:25 PM, Xiao Ni wrote:
On 08/25/2020 06:19 PM, Michal Soltys wrote:
On 8/25/20 7:42 AM, Xiao Ni wrote:
Are those fixes also possibly related to the issues I found earlier
this year about it's very weird discard handling whenever the
originating request wasn't essentially chunk-aligend ?
I searched by your email in my email box and I didn't find emails from
you at earlier this year. Is there a link? Discard request is usually
very big.
Was using different mail then (soltys@xxxxxxxx), but vger seems to be
refusing .info domain now.
If the discard request is not chunk aligned, raid10 can handle this
problem without my patch. It splits I/O by chunk size and write/discard
this chunk to all copies.
What I found back then is e.g. discard of 4x32gb raid10 taking good 11
minutes via blkdiscard w/o explicit step option.
4x32gb means 4 disks and each disk is 32GB?
Using partitions on the disks to be precise, but yea.
For the discard time problem, as mentioned just now, it splits big
discard request into small chunks. So it takes very long time.
My patch resolves this problem.
I still have blktraces of that available, the relevant thread part
with further more detailed followups can be found at:
https://www.spinics.net/lists/raid/msg62115.html
It's a raid456 problem, not raid10.
The part related to raid10 starts at that moment (as well as all
followups), after Song asked me about raid10 behavior.
The above spinics link has links to blktrace dumps when blkdiscard was
executed on such raid10. It was split into tiny chunks and executed in
really weird fashion, that subsequent replies outlined:
https://www.spinics.net/lists/raid/msg62134.html
https://www.spinics.net/lists/raid/msg62164.html
Anyway, just mentioning that after seeing a set of patches related to
discards and raid10.
I'll doublecheck that behavior with more current kernel version and the
patches applied.
