From owner-freebsd-stable@freebsd.org Mon Dec 2 04:30:33 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9B8F71C456D for ; Mon, 2 Dec 2019 04:30:33 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RBxN3M8Jz4c84 for ; Mon, 2 Dec 2019 04:30:32 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id xB24QF1X012522 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 2 Dec 2019 04:26:20 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: bennett@sdf.org Received: from [10.58.0.4] (dadv@[10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id xB24Q8au093939 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Dec 2019 11:26:08 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Slow zfs destroy To: Scott Bennett References: <201911291757.xATHv1P1003382@sdf.org> Cc: freebsd-stable@freebsd.org From: Eugene Grosbein Message-ID: <3a51f9be-7eb8-21a7-b418-580dae58f189@grosbein.net> Date: Mon, 2 Dec 2019 11:26:06 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <201911291757.xATHv1P1003382@sdf.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=4.2 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, HELO_MISC_IP, LOCAL_FROM, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.8 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: * date * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains * 1.1 HELO_MISC_IP Looking for more Dynamic IP Relays X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on eg.sd.rdtc.ru X-Rspamd-Queue-Id: 47RBxN3M8Jz4c84 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.78 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-1.68)[ip: (-4.46), ipnet: 2a01:4f8::/29(-2.35), asn: 24940(-1.58), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 04:30:33 -0000 30.11.2019 0:57, Scott Bennett wrote: > On Thu, 28 Nov 2019 23:18:37 +0700 Eugene Grosbein > 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".) The manual says "zfs destroy -d" is not for "background" but for "deferred". The "zfs destroy" without -d would return EBUSY for a snapshot on hold (zfs hold) or bound with a clone, but "zfs destroy -d" would mark the snapshot for later destruction in a moment the clone is deleted or user lock (hold) is lifted. Until then the snapshot still usable and destruction does not happen. All my snapshots are free from holds or clones and can be deleted, so "zfs destroy -d" is equal to "zfs destroy" for them.