Nexenta/OpenSolaris文件处理程序内核恐慌/崩溃

Question

我有一个运行x4540 Sun存储服务器的NexentaStor企业。它为多个VMWare vSphere主机提供超过10 over的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

Answer 1

这是通过重新创建所有在Nexenta下的zpool来永久解决的。在从OpenSolaris安装中导入zpools时，随身携带了很多行李。当我导入和升级池和文件系统时，稳定性在重建之前并不存在。

Answer 2

我对这个装置一无所知，但是，

ffffff003fefb820 zfs:zap_lockdir+6d ()似乎表示工作线程正在锁定目录，然后mutex_vector_enter也试图锁定它。

这一切似乎都源于从更新配额开始的情况。如果可能的话，如果没有必要的话，你可能会考虑关闭配额。

它只是一个解决办法，而不是一个修复，我不知道它是否会像预期的那样工作！但也许值得一试。

Answer 3

堆栈跟踪引用“用户配额”，这通常不是我们的客户使用的。请注意，它与您也可以设置的文件系统配额是分开的。我鼓励您在可能的情况下关闭用户配额，特别是因为您认为它们是不必要的，但我也鼓励您在有支持合同的情况下提交支持票。这可以从Web发送，然后在票证中包含来自您系统的诊断信息。