PowerScale：NFSv4 的 NFS 核心傾印 GETATTR 要求包含無效的檔案描述項。

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 不是空值。

到目前為止，此問題領域的所有報告都涉及 Solaris NFSv4 用戶端工作流。但是，PowerScale 工程部門也可以使用其他 UNIX 或 Linux 作業系統複製此問題。證據也表明，Solaris 用戶端使用 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 功能，因為 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 ####

對每個受影響的池重複上述步驟。