PowerScale. Дампы ядра NFS из запроса GETATTR NFSv4 с недопустимым дескриптором файла.

Процесс 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 или недопустимым дескриптором файла.

Это приводит к тому, что процесс NFS создает дамп ядра и перезапускается на узле PowerScale, обрабатывая дескриптор корневого файла за секунду GETATTRНо pExecContext > pExport не равно NULL.

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

Для устранения этой проблемы был создан новый дефект: PSCLDF-6198: Invalid Pointer pGattrCtx->pFilePosixInfo causes a core dump.

Постоянное решение: 
Модернизируйте систему до версии OneFS, которая включает это исправление. Технический отдел PowerScale работает над исправлением для этой проблемы. Точных сроков релиза нет.

Решение:
До тех пор, пока не будет применено постоянное решение, можно использовать следующие временные решения для смягчения последствий:

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 или полного доменного имени) приостановленных узлов. При необходимости сотрудники службы поддержки 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 ####

Повторите эти действия для каждого затронутого пула.