> On 5 Apr 2018, at 17:00, Warner Losh <i...@bsdimp.com> wrote: > > I'm working on trim shaping in -current right now. It's focused on NVMe, > but since I'm doing the bulk of it in cam_iosched.c, it will eventually be > available for ada and da. The notion is to measure how long the TRIMs take, > and only send them at 80% of that rate when there's other traffic in the > queue (so if trims are taking 100ms, send them no faster than 8/s). While > this will allow for better read/write traffic, it does slow the TRIMs down > which slows down whatever they may be blocking in the upper layers. Can't > speak to ZFS much, but for UFS that's freeing of blocks so things like new > block allocation may be delayed if we're almost out of disk (which we have > no signal for, so there's no way for the lower layers to prioritize trims > or not).
Have you considered "hard" shaping including discarding TRIMs when needed? Remember that a TRIM is not a write, which is subject to a contract with the application, but a better-if-you-do-it operation. Otherwise, as you say, you might be blocking other operations in the upper layers. I am assuming here that with many devices doing TRIMs is better than not doing them. And in case of queue congestion doing *some* TRIMs should be better than doing no TRIMs at all. Yep, not the first time I propose something of the sort, but my queue of suggestions to eventually discard TRIMs doesn’s implement the same method ;) Borja. _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
