Slow zfs destroy

[Scott Bennett]

     On Thu, 28 Nov 2019 23:18:37 +0700 Eugene Grosbein <eugen at 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         *
**********************************************************************