Date: Thu, 28 Nov 2019 23:18:37 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: Steven Hartland <killing@multiplay.co.uk> Cc: FreeBSD stable <freebsd-stable@freebsd.org> Subject: Re: Slow zfs destroy Message-ID: <7b7a8ed0-2acf-2fc4-7c42-00423cdf4812@grosbein.net> In-Reply-To: <b5d2e7a4-5b0d-44e9-7015-4a33e00eba1e@multiplay.co.uk> References: <01ca3a41-6cd2-823f-a8c1-30a47a0bbc98@grosbein.net> <CAHEMsqbXKZCwRhqcgJkAMGG=o0Jr5TBn90x22XHx=ng-A2=N7A@mail.gmail.com> <49c9c4da-c078-43b9-e7e2-51a1bacb2671@grosbein.net> <b5d2e7a4-5b0d-44e9-7015-4a33e00eba1e@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
28.11.2019 20:34, Steven Hartland wrote: > It may well depend on the extent of the deletes occurring. > > Have you tried disabling TRIM to see if it eliminates the delay? This system used mfi(4) first and mfi(4) does not support TRIM at all. Performance was abysmal. Now it uses mrsas(4) and after switch I ran trim(8) for all SSDs one-by-one then re-added them to RAID1. Disabling TRIM is not an option. Almost a year has passed since then and I suspect SSDs have no or a few spare trimmed cells for some reason. Is there documented way to check this out? Maybe some SMART attribute?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7b7a8ed0-2acf-2fc4-7c42-00423cdf4812>