NFS 服务器重启后 NFS 文件句柄过时:为什么会发生这种情况以及业界如何处理?

NFS 服务器重启后 NFS 文件句柄过时:为什么会发生这种情况以及业界如何处理?

这个问题一直让我抓狂。

我有一台 NFS 服务器,其 NFS 共享安装在各种客户端上。但是,每当我必须重新启动 NFS 服务器时,我总会在所有客户端的安装上看到一堆“过时的文件句柄”错误,这迫使我必须手动卸载客户端上的 NFS 共享并重新安装。

我已经检查了 NFS 服务器上的导出,cat /etc/exports并且在重启后为每个 NFS 导出传递了相同的 fsid。

我的问题:

  1. Industry 如何处理这个问题?我很难想象系统管理员会进入系统并手动卸载/重新安装每个客户端,或者只是批量重新启动连接的客户端。或者这真的是处理方式吗?(除了标准之外,“我们永远不会停机,也永远不必重新启动 NFS 服务器。”)
  2. 为什么会发生这种情况?这是因为,即使 fsid 可能相同,NFS 服务器也会重新计算文件句柄,而文件句柄在重新启动后可能不相同吗?
  3. 我是否应该在挂载配置中做得更好以防止发生这种情况?

/etc/fstab:

[NFSserver]:/mnt/backup /mnt/backup nfs bg,nfsvers=3,tcp 0 0

这个帖子,建议添加hardintr安装选项,但这似乎没有任何区别。

  1. 如果所有其他方法都失败了,我是否应该回到使用 bash 脚本来监视挂载/目录中是否存在陈旧文件错误并让其执行卸载/挂载循环?

提前致谢。

-扭矩扳手

答案1

您正在使用 NFS 版本 3,除了端口 2049 中的主 NFS 服务之外,它还需要几个辅助服务。其中之一是rpc.statd,它在检测重启和重启后恢复/清除 NFS 锁方面发挥着关键作用。

这些辅助服务可能位于随机端口,它们通过联系 RPC 端口映射器(通常是rpcbind现代 Linux 上命名的进程)被发现。在具有防火墙的现代网络中,这种行为可能会使事情变得困难:即使您可能在重新启动后在确定性端口中找到它们,但如果/当您重新启动 NFS 服务时,它们可能会被分配到完全不同的端口号。

幸运的是,在许多现代类 Unix 系统上,您可以锁定 NFS 锁管理器的端口号(历史上rpc.lockd,现在通常在内核中实现),rpc.statdrpc.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.exampleclient.examplerpc.statdclient.example

如果不这样做,一开始一切似乎都运行良好……但是当任一端重新启动时,您可能会收到这些Stale file handle错误。

答案2

除了@telcoM 的出色回答之外,我还想建议另外两种可能的解决方案:

  • 使用noac选项挂载 nfs(请注意,这将要ls在大型目录或许多文件上发布时会导致性能损失stat

  • 使用 NFS v4.1(v4.0 存在一些导致“陈旧文件处理”的错误,因此请务必选择 v4.1 协议)。

相关内容