Nexenta/OpenSolaris filer ядро ​​паника / сбой

У меня сервер хранения x4540 Sun с NexentaStor Enterprise. Он обслуживает NFS более 10GbE CX4 для нескольких хостов VMWare vSphere. Работает 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

3 ответа

Решение

Это было решено навсегда путем воссоздания всех zpools под Nexenta. Было много багажа, перевозимого вместе с zpools, поскольку они были импортированы из установки OpenSolaris. И хотя я импортировал и обновил пулы и файловые системы, стабильности не было, пока все не было восстановлено.

Я ничего не знаю об этой настройке, но,

ffffff003fefb820 zfs: zap_lockdir + 6d () указывает на то, что рабочий поток блокирует каталог, а затем mutex_vector_enter пытается заблокировать его.

Все это, кажется, происходит из ситуации, которая начинается с обновления квоты. Если это возможно, вы можете отключить квоты, если они не нужны.

Это всего лишь обходной путь, а не исправление, и я понятия не имею, будет ли он работать так, как ожидалось! Но, возможно, стоит попробовать.

Трассировка стека ссылается на "пользовательскую квоту", которая обычно не используется нашими клиентами. Обратите внимание, что он не зависит от квот файловой системы, которые вы также можете установить. Я призываю вас отключить пользовательские квоты, если вы можете, особенно если вы считаете, что они не нужны, но я также призываю вас подать заявку в службу поддержки, если у вас есть контракт на поддержку. Это может быть отправлено из веб-интерфейса, который затем включит диагностику из вашей системы в заявку.

Другие вопросы по тегам