Re: Testing devices for discard support properly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 06, 2019 at 04:56:44PM -0400, 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?

Hi Ric,

I think being able to specify workload using fio will be very useful
regardless if we'll end up with with a standalone discard testing tool
or not.

> 
> * What workloads are key?
> 
> Thoughts about what I would start getting timings for:

A long time ago I wrote a tool for testing discaed performance. You can
find it here. Keep in mind that it was really long time ago since I even
looked at it, so not sure if it still even compiles.

https://sourceforge.net/projects/test-discard/

You can go through the README file to see what it does but in summary
you can:

- specify size of discard request
- specify range of discard request size to test
- discard already discarded blocks
- can test with sequential or random pattern
- for every discard request size tested it will give you results like

<record_size> <total_size> <min> <max> <avg> <sum> <throughput in MB/s>

> 
> * Whole device discard at the block level both for a device that has been
> completely written and for one that had already been trimmed

Yes, usefull. Also note that a long time ago when I've done the testing
I noticed that after a discard request, especially after whole device
discard, the read/write IO performance went down significanly for some
drives. I am sure things have changed, but I think it would be
interesting to see how does it behave now.

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

>From my testing (again it was long time ago and things probably changed
since then) most of the drives I've seen had largely the same or similar
timing for discard request regardless of the size (hence, the conclusion
was the bigger the request the better). A small variation I did see
could have been explained by kernel implementation and discard_max_bytes
limitations as well.

> 
> * 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 that all of the above will be interesting. However there are two
sides of it. One is just pure discard performance to figure out what
could be the expectations and the other will be "real" workload
performance. Since from my experience discard can have an impact on
drive IO performance beyond of what's obvious, testing mixed workload
(IO + discard) is going to be very important as well. And that's where
fio workloads can come in (I actually do not know if fio already
supports this or not).

-Lukas

> 
> I think the above would give us a solid base, thoughts or comments?
> 
> Thanks!
> 
> Ric
> 
> 
> 
> 



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux