Re: Testing devices for discard support properly

[Nikolay Borisov <nborisov@suse.com>]

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
> 
> 
> 
>