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

Der NFS-Prozess erstellt kontinuierlich Core-Speicherabbilder und startet auf mehreren PowerScale-Nodes mit dem folgenden Stack-Trace 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 NFSv4 Client sendet eine NFSv4 GETATTR Anfrage mit NULL oder ungültigem Dateideskriptor.

Dies führt dazu, dass der NFS-Prozess ein Core-Dump erstellt und auf dem PowerScale-Node, der ein Root-Datei-Handle verarbeitet, in einer Sekunde neu gestartet wird GETATTRAber pExecContext > pExport ist nicht NULL.

Bisher ging es in allen Berichten zu diesem Thema um Solaris NFSv4 Client-Workflow. Das 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 -Funktion ist möglicherweise anfälliger für die Erhebung des Problems. 

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

Dauerhafte Lösung: 
Führen Sie ein Upgrade auf eine OneFS-Version durch, die die Korrektur enthält. PowerScale Engineering arbeitet an einem Patch für das Problem. Einen genauen Zeitpunkt für die Veröffentlichung gibt es nicht.

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

1. Identifizieren Sie die NFSv4 Clients, die dazu führen, dass NFS einen Core-Speicherabbild erstellt.

Falls erforderlich, kann der Support die IP-Adresse des fehlerhaften Clients über die automatisch generierten Core-Speicherabbilder identifizieren in /var/crash auf den betroffenen Nodes. Erstellen Sie nicht manuell einen Core-Speicherauszug. C Support benötigt den generierten Core-Speicherabbild aus dem Problem gefunden in /var/crash auf den betroffenen Nodes. Der Support kann eine Beratungseskalation erstellen, wenn Unterstützung bei der Identifizierung der Clients erforderlich ist, die das Problem verursachen.

2. Deaktivieren Sie die Option autofs/automount auf den Solaris-Clients funktionieren, da der Support von Dell Technologies davon ausgeht, dass dies mit dem Problem zusammenhängt. Mounten Sie die Exporte stattdessen manuell auf den Solaris-Clients, indem Sie /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 angehalten werden. Kunden können dann die problematischen Solaris-Clients so konfigurieren, dass sie sich direkt mit den IP-Adressen der angehaltenen Nodes verbinden (anstatt den SmartConnect-Zonennamen oder FQDN zu verwenden). Der Support von Dell Technologies kann bei diesem Verfahren bei Bedarf behilflich sein. Wenn der Node angehalten wurde, 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 all Ihren anderen NFS-Clients jetzt daran gehindert werden, eine Verbindung zu diesem Node herzustellen. Allerdings sind alle bereits vorhandenen Verbindungen zu dem Node betroffen. Auch hier besteht das Ziel darin, die Auswirkungen zu verringern, bis eine Patchkorrektur angewendet wird, da nur ein oder zwei NFS-Daemons eines oder zwei Nodes jetzt einen Core-Dump erstellen.

Schritte zum Anhalten eines Nodes 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.