PowerScale : Vidages mémoire NFS à partir d’une requête GETATTR NFSv4 avec un descripteur de fichier non valide.

Le processus NFS effectue des vidages mémoire et redémarre en continu sur plusieurs nœuds PowerScale avec la trace de pile suivante :

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)

Ce problème se produit lorsqu’un système Solaris NFSv4 Le client envoie un NFSv4 GETATTR avec un descripteur de fichier NULL ou non valide.

Cela entraîne le vidage mémoire du processus NFS et son redémarrage sur le nœud PowerScale qui gère un descripteur de fichier racine en une seconde GETATTRMais pExecContext > pExport n’est pas NULL.

À ce jour, tous les rapports dans le domaine de cette question jusqu’à présent ont impliqué Solaris NFSv4 workflow du client. Toutefois, PowerScale Engineering peut également répliquer le problème à l’aide d’autres systèmes d’exploitation UNIX ou Linux. Les preuves indiquent également que les clients Solaris utilisant le autos ou automount peut être plus susceptible d’être à l’origine du problème. 

Un nouveau défaut a été créé pour résoudre le problème : PSCLDF-6198: Invalid Pointer pGattrCtx->pFilePosixInfo causes a core dump.

Solution définitive : 
Effectuez une mise à niveau vers une version de OneFS qui inclut le correctif. Les ingénieurs PowerScale travaillent sur un correctif pour ce problème. Il n’y a pas d’heure exacte pour la sortie.

Contournement:
Tant qu’une solution permanente n’est pas appliquée, les solutions de contournement suivantes peuvent être utilisées pour atténuer l’impact :

1. Identifiez le NFSv4 clients à l’origine du vidage mémoire de NFS.

Si nécessaire, le support peut identifier l’adresse IP du client responsable grâce aux vidages mémoire générés automatiquement disponibles dans /var/crash sur les nœuds concernés. Ne produisez pas de vidage mémoire manuellement. La prise en charge C nécessite le vidage mémoire généré à partir du problème trouvé dans /var/crash sur les nœuds concernés. Le support peut créer une escalade de consultation si une assistance est nécessaire pour identifier les clients à l’origine du problème.

2. Désactivez l’option autofs/automount sur les clients Solaris, car le support Dell Technologies estime que ce problème est lié au problème. Au lieu de cela, montez manuellement les exportations sur les clients Solaris en configurant /etc/vfstab sur le client. 
3. Une fois que le support Dell Technologies a identifié les clients à l’origine du problème, il peut limiter l’impact sur le reste des machines NFS en suspendant 1 à 2 nœuds dans le pool NFS. Les clients peuvent ensuite configurer les clients Solaris problématiques pour qu’ils se connectent directement aux adresses IP (au lieu d’utiliser le nom de zone SmartConnect ou le FQDN) des nœuds suspendus. Le support Dell Technologies peut vous aider dans le cadre de cette procédure, si nécessaire. Une fois le nœud suspendu, les clients Solaris problématiques peuvent désormais se connecter aux nœuds par adresse IP, tandis que les NOUVELLES connexions au FQDN de tous vos autres clients NFS ne peuvent plus se connecter à ce nœud. Toutefois, toutes les connexions préexistantes au nœud sont affectées. Là encore, l’objectif est de réduire l’impact ici, jusqu’à ce qu’un correctif soit appliqué, dans la mesure où seuls les processus NFS d’un ou deux nœuds vident désormais leur mémoire.

Procédure de suspension d’un nœud à partir d’un pool réseau SmartConnect :

Prenons l’exemple du nœud 26 :

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

 Répétez l’opération pour chaque pool concerné.

Pour résumer :

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

Répétez l’opération pour chaque pool concerné.