TRIM, iSCSI and %busy waves

Borja Marcos borjam at sarenet.es
Fri Apr 6 08:07:09 UTC 2018


> On 5 Apr 2018, at 17:00, Warner Losh <imp at 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.




More information about the freebsd-stable mailing list