PowerScale: Dumps de núcleo do NFS da solicitação GETATTR do NFSv4 com um descritor de arquivo inválido.

O processo NFS continuamente despeja e reinicia o núcleo em vários nós do PowerScale com o seguinte rastreamento de pilha:

2025-12-12T09:50:12.851358-08:00 <0.5> powerscale01-28(id28) /boot/kernel.amd64/kernel: [kern_sig.c:4043](pid 6400="nfs")(tid=103190) Stack trace:
2025-12-12T09:50:12.851392-08:00 <0.5> powerscale01-28(id28) /boot/kernel.amd64/kernel: Stack: --------------------------------------------------
2025-12-12T09:50:12.851397-08:00 <0.5> powerscale01-28(id28) /boot/kernel.amd64/kernel: /usr/likewise/lib/lw-svcm/nfs.so:Nfs4AttrGatherAttrs+0x516
2025-12-12T09:50:12.851401-08:00 <0.5> powerscale01-28(id28) /boot/kernel.amd64/kernel: /usr/likewise/lib/lw-svcm/nfs.so:$dtrace1150544965.Nfs4FillAttr+0x736
2025-12-12T09:50:12.851404-08:00 <0.5> powerscale01-28(id28) /boot/kernel.amd64/kernel: /usr/likewise/lib/lw-svcm/nfs.so:$dtrace1209865017.NfsProtoNfs4ProcGetattr+0x515
2025-12-12T09:50:12.851408-08:00 <0.5> powerscale01-28(id28) /boot/kernel.amd64/kernel: /usr/likewise/lib/lw-svcm/nfs.so:$dtrace1357219149.NfsProtoNfs4ProcCompound+0x18a2
2025-12-12T09:50:12.851412-08:00 <0.5> powerscale01-28(id28) /boot/kernel.amd64/kernel: /usr/likewise/lib/lw-svcm/nfs.so:$dtrace1895683854.NfsProtoNfs4Dispatch+0xa31
2025-12-12T09:50:12.851415-08:00 <0.5> powerscale01-28(id28) /boot/kernel.amd64/kernel: /usr/likewise/lib/lw-svcm/nfs.so:NfsExecContextCallback+0x61
2025-12-12T09:50:12.851419-08:00 <0.5> powerscale01-28(id28) /boot/kernel.amd64/kernel: /usr/likewise/lib/liblwsched.so.0:WorkSparkMain+0x4f
2025-12-12T09:50:12.851422-08:00 <0.5> powerscale01-28(id28) /boot/kernel.amd64/kernel: /usr/likewise/lib/liblwbase.so.0:SparkMain+0x142
2025-12-12T09:50:12.851426-08:00 <0.5> powerscale01-28(id28) /boot/kernel.amd64/kernel: --------------------------------------------------
2025-12-12T09:50:12.851429-08:00 <0.6> powerscale01-28(id28) /boot/kernel.amd64/kernel: pid 6400 (nfs), jid 0, uid 0: exited on signal 11 from pid 0 (unknown) (core dumped)

OR

2023-03-01T09:18:00.403811+01:00 <0.5> powerscale01-5(id6) /boot/kernel.amd64/kernel: [kern_sig.c:4026](pid 71661="nfs")(tid=102404) Stack trace:
2023-03-01T09:18:00.403856+01:00 <0.5> powerscale01-5(id6) /boot/kernel.amd64/kernel: Stack: --------------------------------------------------
2023-03-01T09:18:00.403868+01:00 <0.5> powerscale01-5(id6) /boot/kernel.amd64/kernel: /usr/likewise/lib/lw-svcm/nfs.so:Nfs4AttrGatherAttrs+0x50a
2023-03-01T09:18:00.403879+01:00 <0.5> powerscale01-5(id6) /boot/kernel.amd64/kernel: /usr/likewise/lib/lw-svcm/nfs.so:$dtrace1150544965.Nfs4FillAttr+0x700
2023-03-01T09:18:00.403889+01:00 <0.5> powerscale01-5(id6) /boot/kernel.amd64/kernel: /usr/likewise/lib/lw-svcm/nfs.so:$dtrace1209865017.NfsProtoNfs4ProcGetattr+0x5e7
2023-03-01T09:18:00.403900+01:00 <0.5> powerscale01-5(id6) /boot/kernel.amd64/kernel: /usr/likewise/lib/lw-svcm/nfs.so:$dtrace1357219149.NfsProtoNfs4ProcCompound+0x1721
2023-03-01T09:18:00.403911+01:00 <0.5> powerscale01-5(id6) /boot/kernel.amd64/kernel: /usr/likewise/lib/lw-svcm/nfs.so:$dtrace1895683854.NfsProtoNfs4Dispatch+0x402
2023-03-01T09:18:00.403921+01:00 <0.5> powerscale01-5(id6) /boot/kernel.amd64/kernel: /usr/likewise/lib/lw-svcm/nfs.so:$dtrace2038417139.NfsProtoNfs4CallDispatch+0xd0
2023-03-01T09:18:00.403932+01:00 <0.5> powerscale01-5(id6) /boot/kernel.amd64/kernel: /usr/likewise/lib/liblwbase.so.0:SparkMain+0x141
2023-03-01T09:18:00.403943+01:00 <0.5> powerscale01-5(id6) /boot/kernel.amd64/kernel: --------------------------------------------------
2023-03-01T09:18:00.403953+01:00 <0.6> powerscale01-5(id6) /boot/kernel.amd64/kernel: pid 71661 (nfs), uid 0: exited on signal 11 from pid 0 (unknown) (core dumped)

Esse problema ocorre quando um Solaris NFSv4 O cliente envia um NFSv4 GETATTR com um descritor de arquivo NULL ou inválido.

Isso faz com que o processo de NFS core dumpe e reinicie no nó do PowerScale que processa um identificador de arquivo raiz em um segundo GETATTRMas pExecContext > pExport não é NULL.

Até o momento, todos os relatórios no campo desta edição até agora envolveram o Solaris NFSv4 Fluxo de trabalho do client. No entanto, a engenharia do PowerScale também pode replicar o problema usando outros sistemas operacionais UNIX ou Linux. A evidência também indica que os clients Solaris que usam o autos ou automount O recurso pode ser mais propenso a causar o problema. 

Um novo defeito foi criado para resolver o problema: PSCLDF-6198: Invalid Pointer pGattrCtx->pFilePosixInfo causes a core dump.

Solução permanente: 
Faça upgrade para uma versão do OneFS que inclua a correção. A engenharia do PowerScale está trabalhando em um patch para o problema. Não há um horário exato para a liberação.

Solução alternativa:
Até que uma solução permanente seja aplicada, as seguintes soluções temporárias podem ser usadas para reduzir o impacto:

1. Identifique o NFSv4 clients que estão causando o despejo de núcleo do NFS.

Se necessário, o suporte pode identificar o endereço IP do client culpado por meio dos core dumps gerados automaticamente encontrados em /var/crash nos nós afetados. Não produza manualmente um core dump. C O suporte requer o core dump gerado a partir do problema encontrado em /var/crash nos nós afetados. O suporte pode criar um escalonamento de consulta se for necessária assistência para identificar os clientes que estão causando o problema.

2. Desative o autofs/automount nos clients Solaris, pois o suporte da Dell Technologies acredita que isso esteja relacionado ao problema. Em vez disso, monte manualmente as exportações nos clients Solaris configurando /etc/vfstab no cliente. 
3. Depois que o suporte da Dell Technologies identificar os clients que estão causando o problema, eles poderão reduzir o impacto para o restante das máquinas NFS suspendendo 1 a 2 nós no pool de NFS. Os clientes podem então configurar os clients Solaris problemáticos para se conectarem diretamente aos endereços IP (em vez de usar o nome da zona SmartConnect ou FQDN) dos nós suspensos. O suporte da Dell Technologies pode ajudar com esse procedimento, se necessário. Com o nó suspenso, os clients Solaris problemáticos agora podem se conectar aos nós por endereço IP, enquanto quaisquer NOVAS conexões com o FQDN de todos os outros clients NFS agora são impedidas de se conectar a esse nó. No entanto, todas as conexões preexistentes com o nó são afetadas. Novamente, o objetivo é diminuir o impacto aqui, até que uma correção de patch seja aplicada, já que apenas um ou dois daemons NFS do nó agora são core dump.

Etapas para suspender um nó de um pool de rede do SmartConnect:

Usando o nó 26 como exemplo:

# isi network pools sc-suspend-nodes groupnet0.NFS_Subnet.NFS_Pool    26   ***where 26 is lnn #26 ####

 Repita para cada pool afetado.

Para retomar:

# isi network pools sc-resume-nodes  groupnet0.NFS_Subnet.NFS_Pool   26   ***where 26 is lnn #26 ####

Repita para cada pool afetado.