在通过身份验证的挂载请求后挂起NFS服务器的故障排除

Question

我需要一些关于解决科学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输出--没有成功。这个问题甚至在重新启动后仍然存在。任何其他的想法都会受到赞赏。

作为对蒂姆问题的回答:我偶尔在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挂载也不会触发消息。

Answer 1

在syslog或dmesg有什么可疑的吗？我很好奇这个不正常的系统是否有硬件故障。

编辑，好奇您在dmesg中看到的错误，并发现这里提到的相同错误：Linux e1000e (英特尔网络驱动)问题很多，我从哪里开始？

从OP发布的所有调试输出中，我确信他的硬件已经死了，显然有一个内核参数可以修复这个问题：pcie_aspm=off。

您可以尝试使用该参数启动，并查看它是否修复了一切！

Answer 2

确保portmap同时在服务器和客户端上运行。