Date: Fri, 6 Apr 2018 10:56:11 +0200 From: Borja Marcos <borjam@sarenet.es> To: Steven Hartland <killing@multiplay.co.uk> Cc: "Eugene M. Zheganin" <eugene@zhegan.in>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>, Warner Losh <imp@bsdimp.com> Subject: Re: TRIM, iSCSI and %busy waves Message-ID: <9AC3F9CE-B715-4894-B047-38758ACD913C@sarenet.es> In-Reply-To: <CAHEMsqaLSBURNSsx4k8YKBckAWtN2uva36vck5G8jWjhkLLgmQ@mail.gmail.com> References: <92b92a3d-3262-c006-ed5a-dc2f9f4a5cb9@zhegan.in> <CANCZdfrQBqcb5ASPFGjLN=nif4bQ9vTjMtBuDaOvvUKkM7u3XA@mail.gmail.com> <8935E1F4-10DE-4621-8153-26AF851CC26E@sarenet.es> <CAHEMsqaLSBURNSsx4k8YKBckAWtN2uva36vck5G8jWjhkLLgmQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 6 Apr 2018, at 10:41, Steven Hartland <killing@multiplay.co.uk> = wrote: >=20 > That is very hw and use case dependent. >=20 > 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. >=20 > Now admittedly that was a fair few years ago and hw has moved on since = then, but the point remains that it=E2=80=99s 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.=20 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.=20 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=E2=80=99s 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.=20 If the TRIM queue gets very large and the =E2=80=9Cmandatory=E2=80=9D = operations (read, writes, etc) begin to get large delays I think it=E2=80=99s safe to assume that *there is* a = problem and discarding at least part of those TRIMs could help to solve it.=20 A =E2=80=9CTRIM when you can=E2=80=9D should still be better than a = =E2=80=9CDon=E2=80=99t TRIM at all=E2=80=9D.=20 Cheers, Borja. P.S: Attaching the graphs that were lost.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9AC3F9CE-B715-4894-B047-38758ACD913C>