Re: Slow zfs destroy

2019-12-02 Thread Eugene Grosbein
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 th

Re: Slow zfs destroy

2019-12-02 Thread Scott Bennett
Eugene Grosbein wrote: > 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 TR

Re: Slow zfs destroy

2019-12-01 Thread Eugene Grosbein
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? >> >>

Re: Slow zfs destroy

2019-11-29 Thread Scott Bennett
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 sup

Re: Slow zfs destroy

2019-11-28 Thread Eugene Grosbein
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 aft

Re: Slow zfs destroy

2019-11-28 Thread Steven Hartland
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

Re: Slow zfs destroy

2019-11-28 Thread Eugene Grosbein
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 "zf

Re: Slow zfs destroy

2019-11-28 Thread Eugene Grosbein
28.11.2019 16:38, Pete French wrote: > On 28/Nov/2019 07:03, Eugene Grosbein wrote: >> 28.11.2019 13:46, Eugene Grosbein wrote: >> >>> Hi! >>> >>> Is it normal that "zfs destroy" for one ZVOL with attribute "used" equal to >>> 2112939808 bytes (~2GB) >>> takes over two minutes waiting on "tx_sync

Re: Slow zfs destroy

2019-11-28 Thread Pete French
On 28/Nov/2019 07:03, Eugene Grosbein wrote: 28.11.2019 13:46, Eugene Grosbein wrote: Hi! Is it normal that "zfs destroy" for one ZVOL with attribute "used" equal to 2112939808 bytes (~2GB) takes over two minutes waiting on "tx_sync_done_cv"? The pool is RAID1 over five SSDs encrypted wit

Re: Slow zfs destroy

2019-11-27 Thread Steven Hartland
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. On Thu, 28 Nov 2019 at 06:50, Eugene Grosbein wrote: > Hi! > > Is it normal that "zfs destroy" for one ZVOL with attribut

Re: Slow zfs destroy

2019-11-27 Thread Eugene Grosbein
28.11.2019 13:46, Eugene Grosbein wrote: > Hi! > > Is it normal that "zfs destroy" for one ZVOL with attribute "used" equal to > 2112939808 bytes (~2GB) > takes over two minutes waiting on "tx_sync_done_cv"? The pool is RAID1 over > five SSDs encrypted with GELI The pool is *RAIDZ1* > having

Slow zfs destroy

2019-11-27 Thread Eugene Grosbein
Hi! Is it normal that "zfs destroy" for one ZVOL with attribute "used" equal to 2112939808 bytes (~2GB) takes over two minutes waiting on "tx_sync_done_cv"? The pool is RAID1 over five SSDs encrypted with GELI having ZIL and Cache on distinct unencrypted SSD. 11.3-STABLE/amd64 r354667. System h