TRIM, iSCSI and %busy waves

Borja Marcos borjam at sarenet.es
Fri Apr 6 09:05:36 UTC 2018



> On 6 Apr 2018, at 10:41, Steven Hartland <killing at multiplay.co.uk> wrote:
> 
> That is very hw and use case dependent.
> 
> The reason we originally sponsored the project to add TRIM to ZFS was that in our case without TRIM the performance got so bad that we had to secure erase disks every couple of weeks as they simply became so slow they where unusable.
> 
> Now admittedly that was a fair few years ago and hw has moved on since then, but the point remains that it’s not totally true that just not TRIMing is an option.

As far as I know, letting the device know that you have released a block should be a Good Thing. 
So I prefer to TRIM. I have also seen cases where not doing TRIMs resulted in a terrible performance
although modern SSDs should have better algorithms to deal with it. 

But I have also seen bad cases of TRIM requests piling up and clogging the queues for long periods
of time. Admittedly it was a purely synthetic situation (running bonnie++) but, again, performing
operations like destroying a huge snapshot or dataset could trigger a similar condition.  It was
especially nasty when I tried NVMEs. I mentioned this here:

https://lists.freebsd.org/pipermail/freebsd-fs/2016-May/023134.html


That’s why I think there is a mid point between the radical approach of not doing TRIMs at all
and clogging the queues with too many of them. 

If the TRIM queue gets very large and the “mandatory” operations (read, writes, etc) begin to
get large delays I think it’s safe to assume that *there is* a problem and discarding at least part
of those TRIMs could help to solve it. 

A “TRIM when you can” should still be better than a “Don’t TRIM at all”. 

Cheers,





Borja.

P.S: Attaching the graphs that were lost.










More information about the freebsd-stable mailing list