PowerScale: Volcados de núcleo de NFS desde una solicitud GETATTR de NFSv4 con un descriptor de archivo no válido.

El proceso de NFS vuelca y se reinicia continuamente en varios nodos PowerScale con el siguiente seguimiento de la pila:

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)

Este problema se producía cuando un NFSv4 El cliente envía un NFSv4 GETATTR con un descriptor de archivo NULO o no válido.

Esto hace que el proceso de NFS realice un volcado de memoria y se reinicie en el nodo de PowerScale que maneja un identificador de archivo raíz en un segundo GETATTR, pero pExecContext > pExport no es NULL.

Hasta la fecha, todos los informes en el campo de este tema hasta ahora han involucrado a Solaris NFSv4 Flujo de trabajo del cliente. Sin embargo, el equipo de ingeniería de PowerScale también puede replicar el problema mediante otros sistemas operativos UNIX o Linux. La evidencia también indica que los clientes de Solaris que utilizan autos o automount puede ser más propensa a causar el problema. 

Se creó un nuevo fallo para abordar el problema: PSCLDF-6198: Invalid Pointer pGattrCtx->pFilePosixInfo causes a core dump.

Solución permanente: 
Actualice a una versión de OneFS que incluya la corrección. El equipo de ingeniería de PowerScale está trabajando en un parche para el problema. No hay una fecha exacta para el lanzamiento.

Solución alternativa:
Hasta que se aplique una solución permanente, se pueden utilizar las siguientes soluciones alternativas para mitigar el impacto:

1. Identifique el NFSv4 clientes que están causando NFS en el volcado de núcleo.

Si es necesario, el soporte puede identificar la dirección IP del cliente culpable a través de los volcados de núcleo generados automáticamente que se encuentran en /var/crash en los nodos afectados. No produzca manualmente un volcado de memoria. El soporte de C requiere el volcado de memoria generado por el problema que se encuentra en /var/crash en los nodos afectados. El soporte puede crear una escalación de consulta si se necesita ayuda para identificar a los clientes que causan el problema.

2. Deshabilite la opción autofs/automount en los clientes de Solaris, ya que el soporte de Dell Technologies cree que esto se relaciona con el problema. En su lugar, monte manualmente las exportaciones en los clientes de Solaris configurando /etc/vfstab en el cliente. 
3. Una vez que el soporte de Dell Technologies identifica a los clientes que causan el problema, puede mitigar el impacto en el resto de las máquinas NFS mediante la suspensión de 1 a 2 nodos en el pool de NFS. A continuación, los clientes pueden configurar los clientes Solaris problemáticos para que se conecten directamente a las direcciones IP (en lugar de utilizar el nombre de zona de SmartConnect o el FQDN) de los nodos suspendidos. El soporte de Dell Technologies puede ayudar con este procedimiento si es necesario. Con el nodo suspendido, los clientes Solaris problemáticos ahora pueden conectarse a los nodos por dirección IP, mientras que cualquier conexión NUEVA al FQDN desde todos los demás clientes NFS ahora no se puede conectar a este nodo. Sin embargo, todas las conexiones preexistentes al nodo se ven afectadas. Una vez más, el objetivo es disminuir el impacto aquí, hasta que se aplique una corrección de parche, ya que solo uno o dos nodos de los demonios de NFS ahora realizan un volcado de núcleo.

Pasos para suspender un nodo de un pool de red de SmartConnect:

Utilice el nodo 26 como ejemplo:

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

 Repita el procedimiento para cada pool afectado.

Para reanudar:

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

Repita el procedimiento para cada pool afectado.