There are two very different types of TRIM command

Posted May 7, 2019 21:19 UTC (Tue) by masoncl (subscriber, #47138)
In reply to: There are two very different types of TRIM command by walex
Parent article: Issues around discard

I was talking about async discards in a slightly different context. Btrfs and ext4 will block transaction commit until we've finished trimming the things we deleted during the transaction. XFS will allow the commit to finish and let the trims continue floating down in the background, while making sure not to reuse the blocks until the trim is done.

Depending on the device, the async approach can be much faster, but it can also lead to a very large queue of discards, without any way for the application to wait for completion.

to post comments

There are two very different types of TRIM command

Posted May 7, 2019 23:44 UTC (Tue) by walex (guest, #69836) [Link] (2 responses)

“XFS will allow the commit to finish and let the trims continue floating down in the background”

Indeed, but a discard is pretty much like a write, so it could be handled the same way, wo why would XFS do that complicated stuff? The obvious reason is that if discarding is handled synchronously, like Btrfs and ext4 do, then issuing blocking (non queued) TRIM can cause long freezes, which is indeed why many people don't use the discard mount option but use fstrim every now and then at quiet times.

That's why mentioning that there are both blocking and nonblocking TRIMs matters so much, because if non-blocking TRIM is available it effectively works like a write as to queueing too, thus there is very little to be gained from backgrounding TRIMs like XFS does. Apart from love of overcomplexity, which seems rather common in the design of XFS.

Put another way pretty much the entire TRIM debate has been caused by the predominance of blocking TRIM in the SATA installed base of consumer flash SSDs (and the other minor reason has been the numerous TRIM related bugs in many models of flash SSDs, which are just part the numerous bugs of many models of flash SSDs).

There are two very different types of TRIM command

Posted May 8, 2019 15:26 UTC (Wed) by masoncl (subscriber, #47138) [Link]

"That's why mentioning that there are both blocking and nonblocking TRIMs matters so much, because if non-blocking TRIM is available it effectively works like a write as to queueing too, thus there is very little to be gained from backgrounding TRIMs like XFS does. Apart from love of overcomplexity, which seems rather common in the design of XFS."

Actual queueing support for discards does change the math a bit, but the fundamental impact on latency of other operations is still a problem. Sometimes it's worse because you're just allowing the device to saturate itself with slow operations.

The XFS async trim implementation is pretty reasonable, and it can be a big win in some workloads. Basically anything that gets pushed out of the critical section of the transaction commit can have a huge impact on performance. The major thing it's missing is a way to throttle new deletes from creating a never ending stream of discards, but I don't think any of the filesystems are doing that yet.

There are two very different types of TRIM command

Posted May 10, 2019 13:20 UTC (Fri) by GoodMirek (guest, #101902) [Link]

In my eyes, there is a significant difference between write and discard.
If a write fails it can cause a data loss, which is a critical issue and therefore requires transaction safety.
If a discard fails, the worst thing that can happen is some performance and wear deterioration, which is negligible issue.