Nexenta / OpenSolaris filer kernel panic / crash

Question

Tenho um servidor de armazenamento x4540 Sun em execução NexentaStor Enterprise . Ele está servindo NFS acima de 10GbE CX4 para vários hosts do VMWare vSphere. Existem 30 máquinas virtuais em execução.

Nas últimas semanas, tive falhas aleatórias com espaçamento de 10 a 14 dias. Este sistema costumava abrir o OpenSolaris e era estável nesse arranjo. As falhas acionam o recurso de recuperação automatizada do sistema no hardware, forçando uma reinicialização do sistema.

Aqui está a saída do depurador 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 ()

Alguma idéia do que isso significa?

Informação adicional. Não acredito que tenha cotas ativadas no sistema de arquivos ou por usuário.

========== 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

Isto foi resolvido permanentemente recriando todos os zpools sob Nexenta. Havia muita bagagem transportada junto com os zpools quando eram importados de uma instalação do OpenSolaris. E enquanto eu importava e atualizava os pools e sistemas de arquivos, a estabilidade não estava lá até que tudo foi reconstruído.

    

Answer 2

Eu não sei nada sobre essa configuração, mas

ffffff003fefb820 zfs: zap_lockdir + 6d () parece indicar que o segmento de trabalho está bloqueando o diretório e, em seguida, mutex_vector_enter tenta bloqueá-lo também.

Tudo isso parece derivar de uma situação que começa com a atualização da cota. Se for possível, você pode querer considerar desativar as cotas se elas forem desnecessárias.

É apenas uma solução alternativa, e não uma correção, e não tenho ideia se funcionará como esperado! Mas pode valer a pena tentar.

    

Answer 3

O rastreamento de pilha faz referência a "userquota", que normalmente não é usado por nossos clientes. Nota que é separado das cotas do sistema de arquivos que você também pode definir. Eu te encorajo para desativar as cotas de usuários, se possível, especialmente porque você acha que elas são desnecessárias, mas Também o encorajo a registrar um ticket de suporte se você tiver um contrato de suporte. Isso pode ser enviado da GUI da Web, que incluiria diagnósticos de seu sistema no ticket.