Date: Mon, 2 Dec 2019 20:47:14 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: Andriy Gapon <avg@FreeBSD.org>, Scott Bennett <bennett@sdf.org> Cc: freebsd-stable@freebsd.org Subject: Re: Slow zfs destroy Message-ID: <e0e15d86-e574-b5cf-95bc-dd71ac5868a6@grosbein.net> In-Reply-To: <af8025b4-2e96-00fc-adc0-c70783d0472f@FreeBSD.org> References: <201911291757.xATHv1P1003382@sdf.org> <3a51f9be-7eb8-21a7-b418-580dae58f189@grosbein.net> <201912020927.xB29RmLd024059@sdf.org> <af8025b4-2e96-00fc-adc0-c70783d0472f@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
02.12.2019 20:35, Andriy Gapon wrote: > On 02/12/2019 11:27, Scott Bennett wrote: >> The vast majority of my "destroy" operations are for snapshots, but what >> I have seen is that, without the "-d", the command does not return until the >> disk activity of the "destroy" finishes, but with the "-d", it returns within >> a couple of seconds,--i.e., just long enough to get the operation going--and >> the disk I/Os continue until the work is done and free space in the pool increases >> until the I/Os stop. >> Perhaps the man pages for zfs(8) and zpool-features(7) need some modification/ >> clarification on this matter. > > I don't know how to explain what you see, but the manual pages are correct. > -d has nothing to do with asynchronous destroy which is automatic (when enabled). It seems that "zfs destroy" writes and/or removes large enough amount of data to spend lots of time before return when TRIM performance is bad.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e0e15d86-e574-b5cf-95bc-dd71ac5868a6>