![对经过身份验证的挂载请求后 NFS 服务器挂起进行故障排除](https://linux22.com/image/572515/%E5%AF%B9%E7%BB%8F%E8%BF%87%E8%BA%AB%E4%BB%BD%E9%AA%8C%E8%AF%81%E7%9A%84%E6%8C%82%E8%BD%BD%E8%AF%B7%E6%B1%82%E5%90%8E%20NFS%20%E6%9C%8D%E5%8A%A1%E5%99%A8%E6%8C%82%E8%B5%B7%E8%BF%9B%E8%A1%8C%E6%95%85%E9%9A%9C%E6%8E%92%E9%99%A4.png)
我需要一些关于解决 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 输出 - 没有成功。问题甚至在重新启动后仍然存在。任何其他想法都值得赞赏。
作为对 Tim 问题的回答:我偶尔会在 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 安装也不会触发该消息。
答案1
syslog 或 dmesg 中是否有任何可疑内容?我很好奇这个行为异常的系统是否存在硬件故障。
编辑,好奇您在 dmesg 中看到的错误,并发现了这里提到的相同错误:Linux e1000e(英特尔网络驱动程序)问题多多,我该从哪里开始?
从 OP 发布的所有调试输出来看,我确信他的硬件已经坏了,显然有一个内核参数可以解决这个问题:pcie_aspm=off
您可以尝试使用该参数进行启动,看看是否能解决问题!
答案2
确保端口映射在服务器和客户端上都正在运行。