我有一个x4540 Sun存储服务器跑步NexentaStor Enterprise。它通过 10GbE CX4 为多个 VMWare vSphere 主机提供 NFS 服务。有 30 台虚拟机正在运行。
在过去的几周里，每隔 10-14 天，我就会遇到随机崩溃。此系统过去会打开 OpenSolaris，并且在此配置下很稳定。崩溃会触发硬件上的自动系统恢复功能，从而强制进行硬系统重置。
这是mdb 调试器的输出：
panic[cpu5]/thread=ffffff003fefbc60:
Deadlock: cycle in blocking chain
ffffff003fefb570 genunix:turnstile_block+795 ()
ffffff003fefb5d0 unix:mutex_vector_enter+261 ()
ffffff003fefb630 zfs:dbuf_find+5d ()
ffffff003fefb6c0 zfs:dbuf_hold_impl+59 ()
ffffff003fefb700 zfs:dbuf_hold+2e ()
ffffff003fefb780 zfs:dmu_buf_hold+8e ()
ffffff003fefb820 zfs:zap_lockdir+6d ()
ffffff003fefb8b0 zfs:zap_update+5b ()
ffffff003fefb930 zfs:zap_increment+9b ()
ffffff003fefb9b0 zfs:zap_increment_int+68 ()
ffffff003fefba10 zfs:do_userquota_update+8a ()
ffffff003fefba70 zfs:dmu_objset_do_userquota_updates+de ()
ffffff003fefbaf0 zfs:dsl_pool_sync+112 ()
ffffff003fefbba0 zfs:spa_sync+37b ()
ffffff003fefbc40 zfs:txg_sync_thread+247 ()
ffffff003fefbc50 unix:thread_start+8 ()
知道这是什么意思吗？
附加信息。我认为我没有在文件系统或每个用户级别启用任何配额。
========== Volumes and Folders ===========
NAME USED AVAIL REFER MOUNTED QUOTA DEDUP COMPRESS
syspool/rootfs-nmu-000 9.84G 195G 3.84G yes none off off
syspool/rootfs-nmu-001 79.5K 195G 1.16G no none off off
syspool/rootfs-nmu-002 89.5K 195G 2.05G no none off off
syspool/rootfs-nmu-003 82.5K 195G 6.30G no none off off
vol1/AueXXXch 33.9G 1.28T 23.3G yes none on on
vol1/CXXXG 8.72G 1.28T 6.22G yes none on on
vol1/CoaXXXuce 97.8G 1.28T 61.4G yes none on on
vol1/HXXXco 58.1G 1.28T 41.1G yes none off on
vol1/HXXXen 203G 1.28T 90.0G yes none off on
vol1/HXXXny 9.65G 1.28T 8.48G yes none off on
vol1/InXXXuit 2.03G 1.28T 2.03G yes none off on
vol1/MiXXXary 196G 1.28T 105G yes none off on
vol1/RoXXXer 45.5G 1.28T 28.7G yes none off on
vol1/TudXXXanch 6.06G 1.28T 4.54G yes none off on
vol1/aXXXa 774M 1.28T 774M yes none off off
vol1/ewXXXte 46.4G 1.28T 46.4G yes none on on
vol1/foXXXce 774M 1.28T 774M yes none off off
vol1/saXXXe 69K 1.28T 31K yes none off on
vol1/vXXXre 72.4G 1.28T 72.4G yes none off on
vol1/xXXXp 29.0G 1.28T 18.6G yes none off on
vol1/xXXXt 100G 1.28T 52.4G yes none off on
vol2/AuXXXch 22.9G 2.31T 22.9G yes none on on
vol2/FamXXXree 310G 2.31T 230G yes none off on
vol2/LAXXXty 605G 2.31T 298G yes none off on
vol2/McXXXney 147G 2.31T 40.3G yes none off on
vol2/MoXXXri 96.8G 2.31T 32.6G yes none off on
vol2/TXXXta 676G 2.31T 279G yes none off on
vol2/VXXXey 210G 2.31T 139G yes none off on
vol2/vmXXXe2 2.69G 2.31T 2.69G yes none off on
答案1
我对此设置一无所知，但是，
ffffff003fefb820 zfs:zap_lockdir+6d () 似乎表明工作线程正在锁定目录，然后 mutex_vector_enter 也尝试锁定它。
这一切似乎都源于更新配额的情况。如果可能的话，您可能要考虑关闭不必要的配额。
这只是一种解决方法，而不是修复方法，我不知道它是否会按预期工作！但可能值得一试。
答案2
堆栈跟踪引用了“userquota”，我们的客户通常不会使用它。请注意，它与您也可以设置的文件系统配额是分开的。我鼓励您尽可能关闭用户配额，尤其是当您认为它们没有必要时，但我也鼓励您提交支持工单（如果您有支持合同）。这可以从 Web GUI 发送，然后工单中会包含来自您系统的诊断信息。
答案3
通过在 Nexenta 下重新创建所有 zpools，这个问题得到了永久解决。由于 zpools 是从 OpenSolaris 安装中导入的，因此它们带来了很多负担。虽然我导入并升级了池和文件系统，但直到重建所有内容后，稳定性才得以实现。