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 客户端发送包含九个操作的复合请求 (PUTFH, SAVEFH, LOOKUP, GETFH, GETATTR, RESTOREFH, NVERIFY, GETATTR, ACCESS)。在处理 GETATTR 服务器调用的操作 Nfs4AttrGatherAttrs，其中取消引用 pGattrCtx->pFilePosixInfo->Uid。在故障转储中 pGattrCtx 是一个有效的指针，但 pFilePosixInfo 为 NULL，导致分段故障（信号 11）和核心转储。该缺陷已得到重现和跟踪，目前正在开发修复（状态为正在进行中）。

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

为解决此问题，创建了一个新缺陷： PSCLDF-6198: Invalid Pointer pGattrCtx->pFilePosixInfo causes a core dump。

永久解决方案：
升级到即将推出的 OneFS 版本之一，其中包括以下修复：

• OneFS 9.10.1.8（（9.10.1.8 应在 2026 年 6 月底左右准备就绪）
• OneFS 9.14（发布日期待定）

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

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

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

2. 禁用 autofs/automount 在 Solaris 客户端上运行，因为 Dell Technologies 支持人员认为这与此问题有关。相反，通过配置 /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 ####

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