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. My big question here is this: - is "discard" even relevant for future devices? i.e. before we start saying "we want discard to not suck", perhaps we should list all the specific uses we ahve for discard, what we expect to occur, and whether we have better interfaces than "discard" to acheive that thing. Indeed, we have fallocate() on block devices now, which means we have a well defined block device space management API for clearing and removing allocated block device space. i.e.: FALLOC_FL_ZERO_RANGE: Future reads from the range must return zero and future writes to the range must not return ENOSPC. (i.e. must remain allocated space, can physically write zeros to acheive this) FALLOC_FL_PUNCH_HOLE: Free the backing store and guarantee future reads from the range return zeroes. Future writes to the range may return ENOSPC. This operation fails if the underlying device cannot do this operation without physically writing zeroes. FALLOC_FL_PUNCH_HOLE | FALLOC_FL_NO_HIDE_STALE: run a discard on the range and provide no guarantees about the result. It may or may not do anything, and a subsequent read could return anything at all. IMO, trying to "optimise discard" is completely the wrong direction to take. We should be getting rid of "discard" and it's interfaces operations - deprecate the ioctls, fix all other kernel callers of blkdev_issue_discard() to call blkdev_fallocate() and ensure that drive vendors understand that they need to make FALLOC_FL_ZERO_RANGE and FALLOC_FL_PUNCH_HOLE work, and that FALLOC_FL_PUNCH_HOLE | FALLOC_FL_NO_HIDE_STALE is deprecated (like discard) and will be going away. So, can we just deprecate blkdev_issue_discard and all the interfaces that lead to it as a first step? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
