From: Ric Wheeler <ricwheeler@gmail.com>
To: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
lczerner@redhat.com
Subject: Testing devices for discard support properly
Date: Mon, 6 May 2019 16:56:44 -0400 [thread overview]
Message-ID: <4a484c50-ef29-2db9-d581-557c2ea8f494@gmail.com> (raw)
(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?
Thanks!
Ric
next reply other threads:[~2019-05-06 20:56 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-06 20:56 Ric Wheeler [this message]
2019-05-07 7:10 ` Testing devices for discard support properly Lukas Czerner
2019-05-07 8:48 ` Jan Tulak
2019-05-07 9:40 ` Lukas Czerner
2019-05-07 12:57 ` Ric Wheeler
2019-05-07 15:35 ` Bryan Gurney
2019-05-07 15:44 ` Ric Wheeler
2019-05-07 20:09 ` Bryan Gurney
2019-05-07 21:24 ` Chris Mason
2019-06-03 20:01 ` Ric Wheeler
2019-05-07 8:21 ` Nikolay Borisov
2019-05-07 22:04 ` Dave Chinner
2019-05-08 0:07 ` Ric Wheeler
2019-05-08 1:14 ` Dave Chinner
2019-05-08 15:05 ` Ric Wheeler
2019-05-08 17:03 ` Martin K. Petersen
2019-05-08 17:09 ` Ric Wheeler
2019-05-08 17:25 ` Martin K. Petersen
2019-05-08 18:12 ` Ric Wheeler
2019-05-09 16:02 ` Bryan Gurney
2019-05-09 17:27 ` Ric Wheeler
2019-05-09 20:35 ` Bryan Gurney
2019-05-08 21:58 ` Dave Chinner
2019-05-09 2:29 ` Martin K. Petersen
2019-05-09 3:20 ` Dave Chinner
2019-05-09 4:35 ` Martin K. Petersen
2019-05-08 16:16 ` Martin K. Petersen
2019-05-08 22:31 ` Dave Chinner
2019-05-09 3:55 ` Martin K. Petersen
2019-05-09 13:40 ` Ric Wheeler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4a484c50-ef29-2db9-d581-557c2ea8f494@gmail.com \
--to=ricwheeler@gmail.com \
--cc=axboe@kernel.dk \
--cc=lczerner@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox