
這個問題一直讓我抓狂。
我有一個 NFS 伺服器,在各個客戶端上安裝了 NFS 共用。然而,每當我必須重新啟動 NFS 伺服器時,我總是會在所有客戶端的掛載上出現一堆「陳舊檔案句柄」錯誤,這迫使我必須手動卸載並重新掛載客戶端上的 NFS 共用。
我已經檢查了 NFS 伺服器上的匯出,cat /etc/exports
並且在重新啟動後為每個 NFS 導出傳遞相同的 fsid。
我的問題:
- 工業界如何處理這個問題?我很難想像系統管理員會手動卸載/重新安裝每個客戶端,或簡單地重新啟動所有連接的客戶端。或者這真的是這樣處理的嗎? (除了標準之外,「我們永遠不會停機,也永遠不需要重新啟動 NFS 伺服器。」)
- 為什麼會出現這種情況?這是因為,即使 fsid 可能相同,NFS 伺服器也會重新計算檔案句柄,而這些句柄在重新啟動後可能會不相同?
- 我應該在安裝配置中做一些更好的事情來防止這種情況發生嗎?
/etc/fstab:
[NFSserver]:/mnt/backup /mnt/backup nfs bg,nfsvers=3,tcp 0 0
每這個帖子,建議添加hard
和intr
安裝選項,但這似乎沒有任何區別。
- 如果所有其他方法都失敗了,我是否應該回退到使用 bash 腳本來監視掛載/目錄中的過時文件錯誤並讓它執行卸載/掛載循環?
提前致謝。
-扭力扳手
答案1
您使用的是 NFS 版本 3,除了連接埠 2049 中的主 NFS 服務之外,它還需要多個輔助服務rpc.statd
。作用。
這些幫助程式服務可能位於隨機連接埠中,並且透過聯絡 RPC 連接埠映射器(通常是rpcbind
現代 Linux 上命名的進程)來發現它們。在具有防火牆的現代網路中,這種行為可能會讓事情變得困難:即使您在重新啟動後可能會在看起來確定的連接埠中找到它們,但如果/當您重新啟動NFS 服務時,它們可能會被分配到完全不同的連接埠號碼。
幸運的是,在許多現代類 Unix 系統上,您可以鎖定 NFS 鎖管理器的連接埠號碼(歷史上是這樣rpc.lockd
,現在通常在核心中實現),rpc.statd
並且rpc.mountd
.如果您希望 NFSv3 以任何可靠性通過防火牆,這一點至關重要。
對於 RHEL 和相關發行版,您可以透過在下列位置新增以下行來鎖定 NFS 幫助程式連接埠號碼/etc/sysconfig/network
:
LOCKD_TCPPORT=4045
LOCKD_UDPPORT=4045
STATD_PORT=4046
MOUNTD_PORT=4047
對於 Debian 和相關發行版,您可以將此行新增至/etc/modprobe.d/nfs.conf
:
options lockd nlm_udpport=4045 nlm_tcpport=4045
……這行在/etc/default/nfs-common
:
STATDOPTS="-p 4046"
……這行在/etc/default/nfs-kernel-server
:
RPCMOUNTDOPTS="-p 4047" # you may want to add a --manage-gids option here
(如果您願意,可以使用不同的連接埠號,但 4045 是 Solaris 中 NFSv3 鎖定管理器的預設端口,並且在 HP-UX 11.31 中對其進行硬編碼。)
但 NFSv3 協定還有另一個缺陷。儘管僅使用 IP 位址即可成功掛載 NFS 共享,但 NFSv3 鎖定協定在內部使用主機名稱。客戶端和伺服器都必須透過正確的名稱相互認識,否則 NFS 檔案鎖定和重新啟動後的鎖定恢復將無法運作。每個系統的「正確名稱」是 報告的名稱uname -n
。
因此,如果分別在伺服器和用戶端uname -n
上傳回,那麼您應該確保這些確切的名稱將解析為主機需要用於 NFS 的 IP 位址。換句話說,伺服器必須能夠使用該名稱聯繫客戶端,反之亦然。server.example
client.example
rpc.statd
client.example
如果不這樣做,一開始一切似乎都運作良好......但是當任一端重新啟動時,您可能會收到這些Stale file handle
錯誤。
答案2
除了@telcoM 的出色回答之外,我還想建議另外兩種可能的解決方案:
使用
noac
選項掛載 nfs(請注意,這將要ls
在大目錄或許多檔案上發出時會導致效能損失stat
)使用 NFS v4.1(v4.0 有一些錯誤導致“過時文件處理”,因此請務必選擇 v4.1 協定)。