Назад | Перейти на главную страницу

Устранение неполадок, связанных с зависанием сервера NFS после аутентифицированного запроса на монтирование

Мне нужен совет по устранению проблем с сервером NFS в Scientific Linux (RHEL) 6.1. Журнал на сервере показывает, что был сделан запрос на монтирование с аутентификацией:

Jan 13 16:30:02 ??? rpc.mountd[3996]: authenticated mount request from ????:784 for /shared-storage/cm/shared (/shared-storage/cm/shared)

Но после этого это не продолжается. На клиенте тоже висит. Интересно то, что у меня есть два сервера NFS, которые должен быть идентичным, и один работает отлично, но другой демонстрирует вышеупомянутое поведение. Проблема также не является полностью постоянной, т.е. е. иногда запрос на монтирование завершается успешно.

Я предполагаю, что проблема должна быть связана с сервером, а не с клиентом, потому что он отлично работает на другом сервере. Мой вопрос в том, где мне искать проблему. Я уже воссоздал экспорт с помощью exportfs -r, я перезапустил сервер NFS, я сравнил выходы rpcinfo обоих серверов - безуспешно. Проблема сохраняется даже после перезагрузки. Любые другие идеи приветствуются.

В качестве ответа на вопрос Тима: у меня время от времени встречается следующее в dmesg, но я не знаю, связано ли это

e1000e 0000:0c:00.0: eth4: Detected Hardware Unit Hang:
  TDH                  <24>
  TDT                  <25>
  next_to_use          <25>
  next_to_clean        <24>
buffer_info[next_to_clean]:
  time_stamp           <1c3d12940>
  next_to_watch        <24>
  jiffies              <1c3d12940>
  next_to_watch.status <0>
MAC Status             <80383>
PHY Status             <792d>
PHY 1000BASE-T Status  <7800>
PHY Extended Status    <3000>
PCI Status             <10>

Дальнейшее редактирование: указанная выше проблема не возникает на работающем компьютере, поэтому, вероятно, это связано.

Снова редактирование: ошибка не на (программном) устройстве, которое используется для NFS, а на другом. Монтирование NFS также не вызывает сообщения.

Убедитесь, что portmap запущен как на сервере, так и на клиенте.

Что-нибудь в syslog или dmesg кажется подозрительным? Мне любопытно, есть ли проблемы с оборудованием в плохо работающей системе.

Отредактируйте, заинтересовавшись вашей ошибкой, которую вы видели в dmesg, и обнаружили ту же ошибку, упомянутую здесь: Linux e1000e (сетевой драйвер Intel) проблем много, с чего начать?

Из всех отладочных данных, опубликованных OP, я был УВЕРЕН, что его оборудование было почти мертвым, по-видимому, был параметр ядра для устранения проблемы: pcie_aspm=off

Вы можете попробовать загрузиться с этим параметром и посмотреть, исправит ли он ситуацию!