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