PowerScale: Дампи ядра NFS із запиту NFSv4 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 або Invalid File Descriptor.

Це змушує процес NFS перезавантажувати ядро на вузлі PowerScale, який обробляє дескриптор кореневого файлу, за секунду GETATTR, але pExecContext > pExport не є NULL.

На сьогодні всі звіти з цього питання стосувалися Solaris NFSv4 Робочий процес клієнта. Однак PowerScale Engineering може відтворити цю проблему за допомогою інших операційних систем UNIX або Linux. Докази також свідчать, що клієнти Solaris використовують autos або automount Функція може бути більш схильною до виникнення проблеми. 

Створено новий дефект для вирішення проблеми: PSCLDF-6198: Invalid Pointer pGattrCtx->pFilePosixInfo causes a core dump.

Постійне рішення: 
Оновіть до версії OneFS, яка містить це виправлення. PowerScale Engineering працює над патчем для цієї проблеми. Точного часу для релізу немає.

Обхідний шлях:
Поки не буде застосовано постійне рішення, можна застосувати такі обхідні шляхи для пом'якшення наслідків:

1. Визначте NFSv4 клієнти, які спричиняють дамп ядра NFS.

За потреби підтримка може ідентифікувати винну IP-адресу клієнта за допомогою автозгенерованих дампів ядра, знайдених у /var/crash на уражених вузлах. Не створюйте ручного скидання ядра. Підтримка C вимагає згенерованого ядра дампу з проблеми, виявленої у /var/crash на уражених вузлах. Підтримка може організувати ескалацію консультації, якщо потрібна допомога у виявленні клієнтів, які спричиняють проблему.

2. Вимкніть autofs/automount функції на клієнтах Solaris, оскільки підтримка Dell Technologies вважає, що це пов'язано з проблемою. Натомість вручну монтуйте експорти на клієнтах Solaris, налаштувавши /etc/vfstab на клієнті. 
3. Після того, як підтримка Dell Technologies визначить клієнтів, які спричиняють проблему, вони можуть зменшити вплив на інші машини NFS, призупиняючи 1-2 вузли в пулі NFS. Клієнти можуть налаштувати проблемні клієнти Solaris для прямого підключення до IP-адрес (замість використання назви зони SmartConnect або FQDN) підвішених вузлів. Підтримка Dell Technologies може допомогти з цим процесом за потреби. Після призупинення вузла проблемні клієнти Solaris тепер можуть підключатися до вузлів за IP-адресою, тоді як будь-які НОВІ з'єднання з FQDN від усіх інших клієнтів NFS тепер не можуть підключатися до цього вузла. Однак будь-які вже існуючі з'єднання з вузлом зачіпаються. Знову ж таки, мета — зменшити вплив, поки не буде застосовано патч-фікс, коли лише один або два 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 ####

Повторюйте для кожного ураженого пулу.