Re: Slow zfs destroy
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? ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Slow zfs destroy
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 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 "zfs destroy" supposed to perform actual removal in background? "feature@async_destroy" is "enabled" for this pool. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: No amdtemp sysctls, AMD Ryzen 5 3600X
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_ID_AMD_15H_M60H_ROOT 0x1576
#define PCI_DEVICE_ID_AMD_17H_ROOT 0x1450
#define PCI_DEVICE_ID_AMD_17H_M10H_ROOT 0x15d0
+#define PCI_DEVICE_ID_AMD_17H_M30H_ROOT 0x1480
struct pciid;
struct amdsmn_softc {
@@ -90,6 +91,12 @@
.amdsmn_addr_reg = F17H_SMN_ADDR_REG,
.amdsmn_data_reg = F17H_SMN_DATA_REG,
},
+ {
+ .amdsmn_vendorid = CPU_VENDOR_AMD,
+ .amdsmn_deviceid = PCI_DEVICE_ID_AMD_17H_M30H_ROOT,
+ .amdsmn_addr_reg = F17H_SMN_ADDR_REG,
+ .amdsmn_data_reg = F17H_SMN_DATA_REG,
+ },
};
/*
Index: sys/dev/amdtemp/amdtemp.c
===
--- sys/dev/amdtemp/amdtemp.c (revision 355171)
+++ sys/dev/amdtemp/amdtemp.c (working copy)
@@ -96,6 +96,7 @@
#define DEVICEID_AMD_MISC16_M30H 0x1583
#define DEVICEID_AMD_HOSTB17H_ROOT 0x1450
#define DEVICEID_AMD_HOSTB17H_M10H_ROOT 0x15d0
+#define DEVICEID_AMD_HOSTB17H_M30H_ROOT 0x1480
static const struct amdtemp_product {
uint16_t amdtemp_vendorid;
@@ -118,6 +119,7 @@
{ VENDORID_AMD, DEVICEID_AMD_MISC16_M30H, true },
{ VENDORID_AMD, DEVICEID_AMD_HOSTB17H_ROOT, false },
{ VENDORID_AMD, DEVICEID_AMD_HOSTB17H_M10H_ROOT, false },
+ { VENDORID_AMD, DEVICEID_AMD_HOSTB17H_M30H_ROOT, false },
};
/*
On 15.11.19 15:07, Mark Martinec wrote:
On 15/11/2019 3:27 am, Mark Martinec wrote:
Running 12.1-RELEASE-p1 on AMD Ryzen 5 3600X cpu,
but I don't see any temperatures reported in sysctl,
even though amdtemp.ko and amdsmn.ko are loaded
and they don't produce any complaints on loading.
2019-11-15 03:01, Kubilay Kocak wrote:
Resolver of original Ryzen 2 temperature support:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218264
"In Progress" issue for Ryzen 5 support with patch:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239607
I have applied the patch from Bug 239607 and it works now!
Perfect, thanks!
Was committed to head (CURRENT), apparently merged to stable/12
(cant find the MFC commit).
I've updated/retriaged the issue, and asked about a merge to
stable/11, but at this point it looks like it missed the 12.1-RELEASE
window
It's unfortunate that it missed the 12.1-RELEASE.
Thanks for a quick response!
Mark
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Slow zfs destroy
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 "zfs destroy" supposed to perform actual removal in background? "feature@async_destroy" is "enabled" for this pool. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Slow zfs destroy
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_done_cv"? The pool is RAID1 over >>> five SSDs encrypted with GELI >> >> The pool is *RAIDZ1* > > Not normal, no. Having said that I have seen zfs destory take a very lng time > on occasion, > but for a 2GB volume then thats surprisng. Is there actual disc activity > during this time ? Yes, a lot. Several rsync instances writing to another ZFS (mounted file systems) in parallel: copying data over ssh from remote hosts (backups). ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Slow zfs destroy
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 with GELI The pool is *RAIDZ1* Not normal, no. Having said that I have seen zfs destory take a very lng time on occasion, but for a 2GB volume then thats surprisng. Is there actual disc activity during this time ? I've been using 12 a while now, and I don't recall seeing this recently, so maybe its soemthing which has been improved on over 11. -pete. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
