我在 VMSphere 中设置了 Ubuntu 11.10 VM。我正在 nfs 挂载上存储一些数据。VM 经常出现故障。我无法确定原因，但我认为这与此错误有关：
Jan 19 09:53:07 ws-test-moodlearchive-01 kernel: [ 384.523617] nfs4_reclaim_open_state: Lock reclaim failed!
它会在 /var/log/syslog 中出现数千次。最常见的情况是在 cron 开始运行之后。
我最初将一个 cron 作业的输出保存到存储在 NFS 挂载上的文本文件中。将其切换到本地磁盘似乎减少了错误数量，但错误仍然会出现。
Google 一直没什么帮助，我找到的似乎都不适用。在这个网站或 StackOverflow 上找不到任何与之接近的东西。
那么，这个错误意味着什么？我该如何避免它发生？
答案1
我连接的 NFS 服务器运行的是版本 3。我连接的是版本 4。切换到版本 3 似乎已经解决了问题。我不再在系统日志中看到 nfs4_reclaim_open_state 错误。
为了使 NFS 在连接时使用版本 3，我在 fstab 文件中添加了 nfsvers=3。因此，像这样的条目：
nfsserverip:/export/homes /home nfs rw 0 0
变成：
nfsserverip:/export/homes /home nfs nfsvers=3,rw 0 0
我还没弄清楚错误信息到底在告诉我什么。但至少我修复了它。
答案2
实际上这不会在 NFS3 中显示，因为这是仅有 NFS4 的代码，NFS3 没有此功能：) NFS3 具有不同的错误恢复，它可能只是隐藏了问题。
当 NFS4 客户端完成操作但出现错误并尝试从中恢复时，可能会发生这种情况。恢复时，如果 NFS 尝试重新获得锁定但失败，将显示此错误。
锁回收失败的原因有很多，比如 nfs 服务器中的一些错误或竞争，网络问题等。如果您认为这是一个问题，则必须执行 tcpdump 来捕获 NFS 流量（最好是客户端），并尝试在错误出现之前了解请求流，首先了解某些未知的 NFS4 操作失败的原因，然后了解锁回收期间发生了什么
因此，首先要检查的可能是网络，检查电缆、交换机和端口错误、重复的 IP、错误的绑定/LACP、数据包丢失等
答案3
如果客户端未在“NFS4 租约时间”内续订锁定，则 NFS 4 服务器可以清除客户端的锁定（以及所有状态信息）。一旦清除，它们就无法“回收”，尽管应用程序在获悉错误（通常以 EIO - IO 错误的形式出现）后可以请求新锁定。客户端应用程序对此类事件的反应程度取决于应用程序代码及其错误恢复技能。
NFS4 租约时间设置得越短，您就越有可能出现临时通信间隙，而这种间隙足以让 NFS 服务器清除客户端的状态信息和锁定。Linux NFS 服务器通常默认为 90 秒，这是相当不错的保护。但是，不完全了解租约时间影响的人通常会大幅降低此值。此外，一些非 Linux NFS 服务器默认为低得多的值。例如，NetApp NFS 服务器默认为 30 秒，这不能提供针对短暂网络中断的保护。
因此一个原因/解决方案是：NFS 服务器的租赁时间太低，需要提高。
另一个原因：如果客户端和服务器之间的网络高度可靠，发生这种情况的可能性就会降低。因此，检查所有网络硬件/固件是否存在任何降低可靠性的因素非常重要。
如果正在使用群集，有时这些错误对应于 NFS 服务器群集必须将 NFS 导出资源故障转移到另一个节点的事件。精心设计的 NFS4 服务器群集可以保留从一个节点到另一个节点的锁定状态，但大多数人的 NFS4 群集设计得并不好。因此，NFS4 导出的每个群集资源迁移都可能导致锁定（和其他状态）丢失，从而导致客户端记录此类错误，这种情况相当常见。因此，可能需要检查群集设计，以确保完成必要的设计和配置以保留锁定和状态（在故障转移和迁移期间）。
是的，NFS v3 不允许 NFS 服务器仅仅因为客户端没有更新锁而清除锁（这个概念在 v3 中甚至不存在），所以这种确切的情况不会出现。