PowerScale: Zrzuty rdzenia NFS z żądania GETATTR NFSv4 z nieprawidłowym deskryptorem pliku.

Proces NFS w sposób ciągły wykonuje zrzuty rdzenia i uruchamia się ponownie w wielu węzłach PowerScale z następującym śladem stosu:

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)

Ten problem występuje, gdy Solaris NFSv4 klient wysyła NFSv4 GETATTR żądanie z NULL lub nieprawidłowym deskryptorem pliku.

Powoduje to, że proces NFS w ciągu sekundy wykonuje zrzut rdzenia i ponownie uruchamia się w węźle PowerScale, obsługując uchwyt pliku głównego GETATTRAle pExecContext > pExport nie ma wartości NULL.

Do tej pory wszystkie zgłoszenia w tym zakresie dotyczyły Solarisa NFSv4 przepływ pracy klienta. Zespół PowerScale Engineering może jednak odtworzyć ten problem także w innych systemach operacyjnych UNIX lub Linux. Dowody wskazują również, że klienci Solaris korzystający z autos lub automount funkcja może być bardziej podatna na przyczynę problemu. 

W celu rozwiązania tego problemu utworzono nową usterkę: PSCLDF-6198: Invalid Pointer pGattrCtx->pFilePosixInfo causes a core dump.

Trwałe rozwiązanie: 
Uaktualnij system OneFS do wersji zawierającej tę poprawkę. Inżynierowie PowerScale pracują nad poprawką rozwiązującą ten problem. Nie ma dokładnego czasu premiery.

Obejście:
Dopóki trwałe rozwiązanie nie zostanie zastosowane, można zastosować następujące obejścia w celu złagodzenia tego wpływu:

1. Zidentyfikuj NFSv4 klientów, którzy powodują zrzut rdzenia NFS.

W razie potrzeby dział pomocy technicznej może zidentyfikować winowajcę adresu IP klienta na podstawie automatycznie wygenerowanych zrzutów rdzenia znajdujących się w /var/crash w węzłach, których dotyczy problem. Nie należy ręcznie tworzyć zrzutu rdzenia. Obsługa języka C wymaga wygenerowanego zrzutu rdzenia na podstawie problemu znalezionego w /var/crash w węzłach, których dotyczy problem. Dział pomocy technicznej może utworzyć konsultację eskalacyjną, jeśli potrzebna jest pomoc w zidentyfikowaniu klientów powodujących problem.

2. Wyłącz funkcję autofs/automount na klientach z systemem Solaris, ponieważ dział wsparcia firmy Dell Technologies uważa, że jest to związane z problemem. Zamiast tego należy ręcznie zainstalować eksporty na klientach z systemem Solaris, konfigurując /etc/vfstab na kliencie. 
3. Gdy dział pomocy technicznej firmy Dell Technologies zidentyfikuje klientów powodujących problem, może złagodzić wpływ na pozostałe komputery NFS, zawieszając 1–2 węzły w puli NFS. Klienci mogą następnie skonfigurować problematycznych klientów Solaris tak, aby łączyli się bezpośrednio z adresami IP (zamiast używać nazwy strefy SmartConnect lub nazwy FQDN) zawieszonych węzłów. W razie potrzeby dział pomocy technicznej firmy Dell Technologies może pomóc w wykonaniu tej procedury. Po zawieszeniu węzła problematyczne klienty Solaris mogą teraz łączyć się z węzłami według adresu IP, podczas gdy wszystkie NOWE połączenia z nazwą FQDN ze wszystkich innych klientów NFS nie mogą teraz łączyć się z tym węzłem. Ma to jednak wpływ na wszystkie istniejące wcześniej połączenia z węzłem. Ponownie, celem jest zmniejszenie wpływu na środowisko, dopóki nie zostanie zastosowana poprawka, ponieważ tylko demony NFS jednego lub dwóch węzłów są teraz zrzutem rdzenia.

Etapy zawieszania węzła w puli sieci SmartConnect:

Używając węzła 26 jako przykładu:

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

 Powtórz tę czynność dla każdej puli, której dotyczy problem.

Aby wznowić:

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

Powtórz tę czynność dla każdej puli, której dotyczy problem.