☰

重新初始化 NFS 客户端而不重新启动

tag-icon • tag-icon nfs
重新初始化 NFS 客户端而不重新启动

我一直在我的服务器上工作，我使用 NFS 从中导出一个目录。当然，在服务器重新启动的一周左右的时间里，我多次忘记在我的工作站中导出文件系统（从启动时umount安装）。/etc/fstab在这之间我能够umount事后重新安装（我是不是使用autofs）：

umount -fl /data0
mount /data0

但这不再有效。

我不能将服务器导出的目录挂载到不同的目录（挂载挂起），但我能nfs 将导出的目录安装在我的工作站上运行的虚拟机上。

我尝试的是删除 ( rmmod)nfs和nfsv3模块（这不起作用：）Resource temporarily unavailable。lsof挂起。mount不显示任何通过 挂载的内容nfs。这可能是多次使用“umount -l”的结果，但前两次工作没有问题。

我同时重新启动了服务器，因为无法安装而没有任何影响。我也用过service nfs-kernel-server restart。我怀疑如果重新启动客户端工作站，一切都会恢复正常。

有没有办法从中恢复并在我的工作站上重新初始化 nfs 客户端而无需重新启动？
如果我无法在不重新启动的情况下修复此问题，那么如果我开始使用，这种情况不会再次发生吗autofs？

lsof -b最后几行挂起：

lsof: avoiding readlink(/run/user/1001/gvfs): -b was specified.
lsof: avoiding stat(/run/user/1001/gvfs): -b was specified.
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1001/gvfs
      Output information may be incomplete.

在此之前的行中，没有/data0.

条目/etc/fstab：

192.168.0.2:/data0 /data0  nfs  defaults,auto,nolock,user 0 2

答案1

正如 @PaperMonkey 在评论中建议的那样，您可能会被搞砸，因为您使用了默认的安装选项，其中包括永远重试。

intr曾经是一种可以更轻松地中断 I/O 上损坏的 NFS 挂载的事情的方法，但现在它是无操作的。 SIGKILL仍然可以中断卡在 NFS 上的进程，至少nfs(5)声称是这样。有关安装选项，请参阅该手册页。

如果您希望 NFS 永远不再重试，请使用soft而不是默认值。hard

我还建议使用自动安装程序。如果需要，可以在某处创建到 /net/host/foo/bar 的符号链接。

通常重新启动会更容易，但我认为理论上您应该能够kill -9（即kill -KILL）卡在 NFS 上的任何进程。那么 umount -f 可能会起作用。请注意不要让制表符补全导致更多进程卡在 NFS 挂载上。

答案2

以下是在基于 RPM 的发行版上修复此问题所需运行的命令列表。

service rpcbind stop
service nfslock stop
rm -rf /var/lib/nfs/statd/sm/*
rm -rf /var/lib/nfs/statd/sm.bak/*

在那之后：

umount -f /share

答案3

我知道我参加这个聚会真的很晚，但由于我有同样的问题，并且上面的一些答案和评论的部分内容很有用，所以我想总结一下。在我的情况下，我正在使用autofs，我的一个 NFS 安装挂起，umount -f无法工作，并且lsof也挂起。我的 NFS 挂载使用该hard选项等。

您可以使用此命令显示所有正在等待 I/O 的进程的状态、pid 和命令：

ps -e -os,pid,cmd | ps -e -os,pid,cmd | grep ^D

在本例中，^D 是克拉（移位 6）后跟大写 D，而不是控制 D 序列。然后您可以检查这些进程并终止可能与挂起的文件系统相关的进程。所有相关进程都被终止后，您可以使用以下命令卸载文件系统：

卸载-fFS

在哪里FS是挂起的文件系统，之后可以重新挂载。即使在不使用的情况下，此过程也可能有所帮助autofs。我在 Fedora 30 上测试了所有这些。

答案4

使用 lsof 命令的结果查找客户端上保存对过时文件系统的引用的进程并终止这些进程。

umount -f /data0

确保您可以 ping 服务器然后重新安装驱动器。重新启动任何所需的进程。

集群

请注意，如果您运行集群服务器设置，则每次服务器必须进行故障转移时，您都会得到一个过时的 nfs 文件句柄。为避免这种情况，您应该使用 fsid 选项导出文件系统。两台服务器上各自文件系统的 fsid 编号应该相同。由您来确保进行文件复制。请参阅下面的手册页中的片段：

fsid=num|根|uuid NFS 需要能够识别它导出的每个文件系统。通常它会使用文件系统的 UUID（如果文件系统有这样的东西）或保存文件系统的设备的设备号（如果文件系统存储在设备上）。由于并非所有文件系统都存储在设备上，并且并非所有文件系统都有 UUID，因此有时需要显式告诉 NFS 如何识别文件系统。这是通过 fsid= 选项完成的。

对于 NFSv4，有一个独特的文件系统，它是所有导出文件系统的根。这是用 fsid=root 或 fsid=0 指定的，两者的含义完全相同。

其他文件系统可以用一个小整数或包含 32 个十六进制数字和任意标点符号的 UUID 来标识。

Linux 内核版本 2.6.20 及更早版本不理解 UUID 设置，因此如果需要为此类内核设置 fsid 选项，则必须使用小整数。支持设置较小的数字和 UUID，因此可以在新旧内核上使用相同的配置。

相关内容