☰

对经过身份验证的挂载请求后 NFS 服务器挂起进行故障排除

tag-icon • tag-icon mount nfs scientific-linux
对经过身份验证的挂载请求后 NFS 服务器挂起进行故障排除

我需要一些关于解决 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

确保端口映射在服务器和客户端上都正在运行。

相关内容