我有一个中型到大型服务器，我的所有工程用户都在上面。这是一个 32 核、256GB 的系统，托管 19 个 Xvnc 会话以及用户群所暗示的大量工具、登录会话等。所有用户均通过 NIS 配置并在 NFS 上拥有主目录。各种自动化进程也使用 NIS 定义的用户和 NFS 安装的文件系统。
该计算机运行的是 CentOS 6.5，所涉及的文件服务器是 NetApp。
有时，在计算机运行一段时间后，人们会间歇性地遇到删除某些内容的问题；该错误类似于“设备/资源繁忙”。 lsof 没有显示任何有问题的项目（文件或目录）；经过一段不确定的时间（通常少于找到管理员并让他查看问题所需的时间）后，问题就会消失，并且可以删除该项目。
大约在同一时间，使用 SVN 的自动化流程之一出现如下错误：
svn: E155009: Failed to run the WC DB work queue associated with '/home/local-user/tartarus/project8/doc/verif/verification_environment/learning/images', work item 930 (file-install doc/verif/verification_environment/learning/images/my-sequence.uml 1 0 1 1)
svn: E000018: Can't move '/home/local-user/tartarus/project8/.svn/tmp/svn-j3XrNq' to '/home/local-user/tartarus/project8/doc/verif/verification_environment/learning/images/my-sequence.uml': Invalid cross-device link
如果我们尝试删除有问题的文件，我们会得到：
rm: cannot remove `project8/doc/verif/verification_environment/learning': Device or resource busy
谷歌搜索“无效的跨设备链接”会导致很多关于 svn 版本和不支持跨不同设备写入的讨论，这与我们无关，因为这通常有效，而且我们没有运行跨版本 svn 存储库。或者跨设备存储库，因为 .svn 目录与工作副本所在的设备位于同一设备（安装了 nfs）。
重新启动计算机可以让问题在数周或数月内消失——在我目前的情况下，计算机的正常运行时间刚刚达到 185 天。但工程师们并不热衷于不必要地频繁重启他们的世界。
我们已排除文件服务器的原因，因为其他计算机不会出现相同的问题，除非该问题出现在主系统上。也就是说，我们可以重复这样一个事实：如果主系统无法移动/重命名文件，则文件无法移动/重命名，但是其他计算机永远不会独立地表现出这种行为。
NFS 文件系统的挂载选项有：rw,intr,sloppy,addr=10.17.0.199
我认为这必须是某处被过度填充的内核值，要么是工程师正在运行的某些泄漏事物的副作用，要么是由于临时负载而导致的突发。
它不是打开的文件总数，因为该限制类似于 25M 文件，而这台计算机的峰值低于 200K 文件。
有谁知道我应该看/寻找什么？
答案1
简短回答：您的本地 NFS 认为不存在文件或目录。 （是的，你有点怀疑）
NFS 是一项古老的技术。它不适用于高访问量、快速变化的文件。对于动态共享文件系统，请尝试集群解决方案，例如 OCFS2（我的最爱）或 gluster（嗯，Dark Side）。
几年前，我们有 4 台服务器安装了一个通用的 NFS，并且多次发现其中一台服务器会创建其他服务器看不到的文件。这 4 台服务器是 Web 应用程序服务器。用户将启动一个操作，让服务器创建一个包，并在完成后使用该文件的 NFS 路径更新数据库中的一行。用户的浏览器将每隔 10 秒检查一次，看看工作是否完成，以及是否需要下载文件。您可以看到问题即将到来 - 服务器将更新数据库中文件所在的行，但另一台服务器将从用户浏览器获取请求 - 它将读取文件并收到“文件未找到”错误。
正如你所说，当管理员查看它时，文件就在那里。我们几个工程师花了几周时间才找到问题所在。基本上，我们运行了一个 10 秒的睡眠循环，它将获取数据库中指示的最后创建的文件路径，并尝试将文件写入日志。创建该文件的系统始终可以看到该文件，但其他系统在一段时间内看不到该文件。随着服务器负载的增加，时间间隔变得更长。
尖头老板们不想将底层 NFS 更改为集群文件系统，因此我们还让工作服务器保存“他”是在数据库中创建文件的人。用户的请求将不断重试，直到作业完成并且请求到达创建该文件的服务器，以便该文件始终可供读取。是的，我知道。克鲁奇。但这就是当你决定保留旧技术时你会得到的结果——你必须拼凑才能让事情发挥作用。旧技术是第一个拼凑，而与之相关的所有工作都只是更多的拼凑。欢迎回到 80 年代，Max Headroom 的 FS 选择。
NFS 并不能让所有客户端实时同步所有更改。因此，您会不断遇到这样的情况：一个客户端创建文件/目录，而另一个客户端看不到它，或者一个客户端删除文件/目录，而其他客户端认为它仍然存在（直到他们尝试使用它 - 哎呀） ）。
我们尝试了各种技巧，让系统在尝试读取文件之前重新同步其客户端缓存。没有发生。
我的建议：把你的FS带入这个世纪。 （尝试通量电容器 @ 88mph）
答案2
只是一个评论：
错误E155009/E000018也适用于本地跨设备移动：
svn: E155009: Failed to run the WC DB work queue associated with '/first-device/mounted-device', work item 1219 (file-install /first-device/mounted-device/file-to-move-to 1 0 1 1)
svn: E000018: Can't move '/first-device/.svn/tmp/svn-v2KRIt' to '/first-device/mounted-device/file-to-move-to': Invalid cross-device link
因此，它不是 NFS 特定的。