Date: Thu, 28 Nov 2019 13:34:01 +0000 From: Steven Hartland <killing@multiplay.co.uk> To: Eugene Grosbein <eugen@grosbein.net> Cc: FreeBSD stable <freebsd-stable@freebsd.org> Subject: Re: Slow zfs destroy Message-ID: <b5d2e7a4-5b0d-44e9-7015-4a33e00eba1e@multiplay.co.uk> In-Reply-To: <49c9c4da-c078-43b9-e7e2-51a1bacb2671@grosbein.net> References: <01ca3a41-6cd2-823f-a8c1-30a47a0bbc98@grosbein.net> <CAHEMsqbXKZCwRhqcgJkAMGG=o0Jr5TBn90x22XHx=ng-A2=N7A@mail.gmail.com> <49c9c4da-c078-43b9-e7e2-51a1bacb2671@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
It may well depend on the extent of the deletes occurring. Have you tried disabling TRIM to see if it eliminates the delay? Regards Steve On 28/11/2019 09:59, Eugene Grosbein wrote: > 28.11.2019 14:26, Steven Hartland wrote: > >> As you mentioned it’s on SSD you could be suffering from poor TRIM performance from your devices >> if you run gstat -pd you’ll be able to get an indication if this is the case. > Yes, this box does have problems with poor TRIM performance. > But isn't "zfs destroy" supposed to perform actual removal in background? > "feature@async_destroy" is "enabled" for this pool.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b5d2e7a4-5b0d-44e9-7015-4a33e00eba1e>