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
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
Here is the patch to add support for 3rd gen Ryzen to amdtemp:
Index: sys/dev/amdsmn/amdsmn.c
===
--- sys/dev/amdsmn/amdsmn.c (revision 355171)
+++ sys/dev/amdsmn/amdsmn.c (working copy)
@@ -59,6 +59,7 @@
#define PCI_DEVICE
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
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
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
