PowerScale：NFSv4 GETATTR 请求的 NFS 核心转储具有无效的文件描述符。

NFS 进程在多个 PowerScale 节点上持续进行核心转储和重新启动，并执行以下堆栈跟踪：

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)

当 Solaris NFSv4 客户端发送 NFSv4 GETATTR 具有 NULL 或无效文件描述符的请求。

这会导致 NFS 进程在一秒钟内在处理根文件句柄的 PowerScale 节点上进行核心转储并重新启动 GETATTR但 pExecContext > pExport 不是 NULL。

到目前为止，此问题领域的所有报告都涉及 Solaris NFSv4 客户端工作流。但是，PowerScale 工程部门也可以使用其他 UNIX 或 Linux作系统复制问题。证据还表明，使用 autos 或 automount 功能可能更容易导致此问题。

已创建新的缺陷以解决此问题： PSCLDF-6198: Invalid Pointer pGattrCtx->pFilePosixInfo causes a core dump。

永久性解决方案：
升级到包含修复的 OneFS 版本。PowerScale 工程部门正在为此问题开发修补程序。没有确切的发布时间。

解决 方案：
在应用永久解决方案之前，可以使用以下解决方法来减轻影响：

1. 识别 NFSv4 导致 NFS 进行核心转储的客户端。

如果需要，支持人员可以通过在以下位置找到的自动生成的核心转储来识别导致错误的客户端 IP 地址： /var/crash 在受影响的节点上。请勿手动生成核心转储。C 支持需要根据在以下位置找到的问题生成的核心转储： /var/crash 在受影响的节点上。如果需要帮助识别导致问题的客户端，支持人员可以创建咨询上报。

2. 禁用 autofs/automount 在 Solaris 客户端上运行，因为 Dell Technologies 支持人员认为这与问题相关。而是通过配置 在 Solaris 客户端上手动装载导出 /etc/vfstab 在客户端上。 
3. Dell Technologies 支持人员确定导致问题的客户端后，可以通过挂起 NFS 池中的 1-2 个节点来减轻对其余 NFS 计算机的影响。然后，客户可以将有问题的 Solaris 客户端配置为直接连接到挂起的节点的 IP 地址（而不是使用 SmartConnect 分区名称或 FQDN）。如果需要，Dell Technologies 支持人员可以协助执行此过程。挂起节点后，有问题的 Solaris 客户端现在可以通过 IP 地址连接到节点，而从所有其他 NFS 客户端到 FQDN 的任何新连接现在都会被阻止连接到此节点。但是，与节点的任何预先存在的连接都会受到影响。同样，目标是在应用修补程序修复之前减轻此处的影响，因为现在只有一个或两个节点的 NFS 守护程序是核心转储。

从 SmartConnect 网络池 中挂起 节点的步骤：

以节点 26 为例：

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

 对每个受影响的池重复此作。

要 恢复：

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

对每个受影响的池重复此作。