NFS 导致 Linux 系统挂起,例如执行 ls 或 df

NFS 导致 Linux 系统挂起,例如执行 ls 或 df

运行 RHEL 7.9,在 LAN 上使用 cisco 交换机和 6 类有线布线。当出现任何类型的网络问题时,有时据我所知不是网络问题,linux 会因为 NFS 而挂起,在 NFS 客户端上,为什么?

例如

  • 使用默认设置/etc/nfs.conf/etc/sysconfig/nfs未经修改,NFS vers=4.1 很容易发生。
  • 服务器A导出/data
  • /data从服务器 A安装服务器 B
  • 如果出现任何类型的网络挂断,只需拔掉服务器 A 或 B 的 Cat6 电缆并重新连接...网络将重新连接,并且 SSH 等功能将在服务器 A 和 B 之间正常工作,但作为 NFS 客户端的服务器 B 将会遇到这种情况我不知道如何纠正以下类型的问题:
    • NFS 过时句柄/data
    • 执行操作ls /将挂在终端窗口中,直到 ctrl-c 完成
    • 执行 adf -h将挂在终端窗口中,直到 ctrl-c 完成
    • 做一个umount /data也会挂起
    • 看来唯一可靠的修复方法是重新启动 NFS 客户端

有人可以解释为什么会出现这样的问题吗?特别是挂起诸如ls和 之类的事情df?有没有关于如何排除 NFS 故障的指导?当它停止工作时,我觉得我正在使用一个黑匣子,唯一的修复方法就是重新启动。

答案1

下次遇到此问题时,请查看/proc/fs/nfsfs/volumes服务器 B。您应该会发现已安装的 NFS 文件系统列表,其中列出了FSID对于每个。记下悬挂安装的 FSID。然后重新启动客户端,挂载 NFS 卷并再次检查。 FSID 应该保持不变:如果它们发生了变化,那就是原因。


/data如果您的 FSID 不断变化,则执行导出的服务器 A 上导出的实际文件系统类型是什么?

如果该文件系统没有真正的 UUID,或者保存该文件系统的设备的设备编号可能会有所不同(由于服务器 A 上的热插拔或管理操作)。如果出于某种原因,服务器 A 上没有持久 FSID 的有效源,则服务器 A 可能必须动态生成一个。

如果服务器 B 在尝试重新连接到服务器 A 时看到与之前不同的 FSID,则它会假定服务器 B 重新连接到的 NFS 共享与之前不完全相同,并且服务器 B 的任何缓存数据老的份额不一定适用于新的一。

这使服务器 B 陷入困境:任何打开的文件句柄和缓存的数据都专门引用老的显然无处可寻的分享。只是盲目地应用它们新的share 可能是一个导致数据丢失的错误。并且内核将绝不未经明确告知而故意丢失用户数据。

如果内核有缓存数据等待写入老的umount /data共享,那么服务器 B 上的正常操作确实会挂起 - 但umount -l /data应该可以工作。不幸的是,它只会允许您更干净地关闭 - 重新挂载已卸载的共享umount -l可能是不可能的,除非所有持有对已卸载文件系统的引用的进程首先停止这样做。

如果您的 NFS 共享没有固定 FSID,则可能需要在服务器 Afsid=<number>|root|<uuid>上添加一个选项/etc/exports,以指定固定 FSID(有效的 UUID 或单个小整数,以实现旧版兼容性)。

一旦服务器 B 发现服务器 A 上的 NFS 共享在重新连接时具有与初始连接时相同的 FSID,它应该能够自动继续重新连接。

答案2

这就是 NFS 的本质。 90 年代我开始使用 Unix 时就是这样。

您尝试过使用该-o soft选项安装吗?看看是否有帮助。

以下是 nfs 的手册页:

       soft / hard    Determines  the  recovery behavior of the NFS client after an NFS request times out.  If neither option
                      is specified (or if the hard option is specified), NFS requests are retried indefinitely.  If the  soft
                      option  is  specified, then the NFS client fails an NFS request after retrans retransmissions have been
                      sent, causing the NFS client to return an error to the calling application.

                      NB: A so-called "soft" timeout can cause silent data corruption in certain cases. As such, use the soft
                      option  only  when  client responsiveness is more important than data integrity.  Using NFS over TCP or
                      increasing the value of the retrans option may mitigate some of the risks of using the soft option.

答案3

有时您可以使用以下方法恢复它:

 mount -o remount /nfs/mountpoint  

如果失败则可以强制卸载。请注意,这样做存在损坏的风险 - 但可能与重新启动的风险相同。

umount -f /nfs/mountpoint

相关内容