PowerScale: NFS-Core-Speicherabbilder von NFSv4-GETATTR-Anforderung mit einem ungültigen Dateideskriptor.

Der NFS-Prozess erstellt kontinuierlich Core-Speicherabbilder und startet mit dem folgenden Stapel-Trace auf mehreren PowerScale Nodes neu:

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)

Dieses Problem tritt auf, wenn ein Solaris-Server NFSv4 Der Client sendet eine zusammengesetzte Anforderung mit neun Vorgängen. (PUTFH, SAVEFH, LOOKUP, GETFH, GETATTR, RESTOREFH, NVERIFY, GETATTR, ACCESS). Während der Verarbeitung der GETATTR Vorgang, den der Server aufruft Nfs4AttrGatherAttrs, wodurch Dereferenzen pGattrCtx->pFilePosixInfo->Uid. Im Crashdump pGattrCtx ist ein gültiger Zeiger, aber pFilePosixInfo ist NULL, was zu einem Segmentierungsfehler (Signal 11) und einem Core-Speicherabbild führt. Der Fehler wurde reproduziert, zurückverfolgt und eine Korrektur wird derzeit entwickelt (Status In Bearbeitung).

Bisher waren alle Berichte in diesem Bereich an Solaris beteiligt NFSv4 Client-Workflow. PowerScale Engineering kann das Problem jedoch auch mit anderen UNIX- oder Linux-Betriebssystemen replizieren. Es gibt auch Hinweise darauf, dass Solaris-Clients, die die autos oder automount Die Funktion ist möglicherweise anfälliger für das Problem. 

Um das Problem zu beheben, wurde ein neuer Fehler erstellt: PSCLDF-6198: Invalid Pointer pGattrCtx->pFilePosixInfo causes a core dump.

Dauerhafte Lösung:
Führen Sie ein Upgrade auf eine der folgenden kommenden OneFS-Versionen durch, die die folgende Korrektur enthält:

• OneFS 9.10.1.8 ((9.10.1.8 sollte gegen Ende Juni 2026 fertig sein)
• OneFS 9.14 (Veröffentlichungsdatum ausstehend)

Problemumgehung:
Bis eine dauerhafte Lösung angewendet wird, können die folgenden Workarounds verwendet werden, um die Auswirkungen zu mindern:

1. Identifizieren Sie die NFSv4 Clients, die einen Core-Dump von NFS verursachen.

Falls erforderlich, kann der Support die ursächliche Client-IP-Adresse über die automatisch generierten Core-Speicherabbilder identifizieren, die in /var/crash Auf den betroffenen Nodes. Erstellen Sie nicht manuell einen Core-Speicherabbild. C Support erfordert das erzeugte Core-Speicherabbild aus dem Problem in /var/crash Auf den betroffenen Nodes. Der Support kann eine Beratungseskalation erstellen, wenn Unterstützung bei der Identifizierung der Kunden erforderlich ist, die das Problem verursachen.

2. Deaktivieren Sie die autofs/automount auf den Solaris-Clients funktionieren, da der Support von Dell Technologies der Ansicht ist, dass dies mit dem Problem zusammenhängt. Mounten Sie die Exporte stattdessen manuell auf den Solaris-Clients wie folgt /etc/vfstab auf dem Client. 
3. Sobald der Dell Technologies Support die Clients identifiziert hat, die das Problem verursachen, kann er die Auswirkungen auf den Rest der NFS-Maschinen abmildern, indem 1–2 Nodes im NFS-Pool suspendiert werden. Kunden können dann die problematischen Solaris-Clients so konfigurieren, dass sie eine direkte Verbindung zu den IP-Adressen (statt des SmartConnect-Zonennamens oder FQDN) der angehaltenen Nodes herzustellen. Der Dell Technologies Support kann bei Bedarf bei diesem Verfahren behilflich sein. Wenn der Node angehalten ist, können die problematischen Solaris-Clients jetzt eine Verbindung zu den Nodes über die IP-Adresse herstellen, während alle NEUEN Verbindungen zum FQDN von allen anderen NFS-Clients jetzt daran gehindert werden, eine Verbindung zu diesem Node herzustellen. Allerdings sind alle bereits vorhandenen Verbindungen mit dem Node betroffen. Auch hier besteht das Ziel darin, die Auswirkungen zu verringern, bis ein Patchfix angewendet wird, da nur noch ein oder zwei Node-NFS-Daemons Core-Dumps aufweisen.

Schritte zum Anhalten eines Node aus einem SmartConnect-Netzwerkpool:

Am Beispiel von Node 26:

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

 Wiederholen Sie dies für jeden betroffenen Pool.

So fahren Sie fort:

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

Wiederholen Sie dies für jeden betroffenen Pool.