On 6.05.19 г. 23:56 ч., Ric Wheeler wrote:
>
> (repost without the html spam, sorry!)
>
> Last week at LSF/MM, I suggested we can provide a tool or test suite to
> test discard performance.
>
> Put in the most positive light, it will be useful for drive vendors to
> use to qualify their offerings before sending them out to the world. For
> customers that care, they can use the same set of tests to help during
> selection to weed out any real issues.
>
> Also, community users can run the same tools of course and share the
> results.
>
> Down to the questions part:
>
> Â * Do we just need to figure out a workload to feed our existing tools
> like blkdiscard and fio?
>
> * What workloads are key?
>
> Thoughts about what I would start getting timings for:
>
> * Whole device discard at the block level both for a device that has
> been completely written and for one that had already been trimmed
>
> * Discard performance at the block level for 4k discards for a device
> that has been completely written and again the same test for a device
> that has been completely discarded.
>
> * Same test for large discards - say at a megabyte and/or gigabyte size?
>
> * Same test done at the device optimal discard chunk size and alignment
>
> Should the discard pattern be done with a random pattern? Or just
> sequential?
>
> I think the above would give us a solid base, thoughts or comments?
I have some vague recollection this was brought up before but how sure
are we that when a discard request is sent down to disk and a response
is returned the actual data has indeed been discarded. What about NCQ
effects i.e "instant completion" while doing work in the background. Or
ignoring the discard request altogether?
>
> Thanks!
>
> Ric
>
>
>
>
