對經過身份驗證的掛載請求後掛起的 NFS 伺服器進行故障排除

我需要一些關於在 Scientific Linux (RHEL) 6.1 上解決 NFS 伺服器問題的建議。伺服器上的日誌顯示發出了經過身份驗證的掛載請求：

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 掛載也不會觸發該消息。

syslog 或 dmesg 中有什麼可疑的東西嗎？我很好奇行為不端的系統是否存在硬體問題。

編輯，對您在 dmesg 中看到的錯誤感到好奇，並發現此處提到的相同錯誤：Linux e1000e (Intel network driver) questions galore，我從哪裡開始？

從 OP 發布的所有調試輸出中，我確信他的硬體快要死了，顯然有一個核心參數可以解決這個問題：pcie_aspm=off

您可以嘗試使用該參數啟動，看看它是否可以解決問題！

引用自：https://serverfault.com/questions/349678