Date: Fri, 29 Nov 2019 11:57:00 -0600 From: Scott Bennett <bennett@sdf.org> To: Eugene Grosbein <eugen@grosbein.net> Cc: freebsd-stable@freebsd.org Subject: Re: Slow zfs destroy Message-ID: <201911291757.xATHv1P1003382@sdf.org>
next in thread | raw e-mail | index | archive | help
On Thu, 28 Nov 2019 23:18:37 +0700 Eugene Grosbein <eugen@grosbein.net>
wrote:
>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?
>
You neglected to state whether you used "zfs destroy datasetname" or
"zfs destroy -d datasetname". If you used the former, then ZFS did what
you told it to do. If you want the data set destroyed in the background,
you will need to include the "-d" option in the command. (See the zfs(1)
man page at defer_destroy under "Native Properties".)
Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet: bennett at sdf.org *xor* bennett at freeshell.org *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
* -- Gov. John Hancock, New York Journal, 28 January 1790 *
**********************************************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201911291757.xATHv1P1003382>