“过时的文件句柄”错误，当进程尝试读取文件时，该其他进程已被删除

Question

我正在编写压力测试套件，用于通过NFS测试分布式文件系统。

在某些情况下，当某个进程删除文件而其他进程试图从中读取文件时，我收到“陈旧文件句柄”错误（116）。

在这种加薪条件下，这种错误是可以预期的并且可以接受的吗？

测试工作如下：

1. 开始数量x客户端计算机数量
2. 每个客户端计算机运行y个进程
3. 每个进程都可以执行任何文件操作，如stat / read / delete / open
4. 提及的文件操作是标准的python方法-os.stat / read / os.remove / open
5. 所有文件均为空0字节数据

文件存在，如成功stat操作所示：

controller_debug.log.2：2016-10-26 15：02：30,156; INFO-[LG-E27A-LNX：0xa]：已完成640522b4d94c453ea545cb86568320ca，结果：成功| stat | / JUyw481MfvsBHOm1KQu7sHRB6ffAXKjwIATlsXmOgWh8XKQaIrPbxLgAo7sucdAM / o6V266xE8bTaUGzk8YDMfDAJp0YIfbT4fIK1oZ2R20tRX3xFCvjIS 数据：{} | 2016/10/26 15：02：30.156

0x1客户端上的进程CLIENT-A已成功删除：

controller_debug.log.2：2016-10-26 15：02：30,164; INFO-[CLIENT-A：0x1]：已完成5f5dfe6a06de495f851745a78857eec1，结果：成功| 删除| / JUyw481MfvsBHOm1KQu7sHRB6ffAXKjwIATlsXmOgWh8XKQaIrPbxLgAo7sucdAM / o6V266xE8bTaUGzk8YDMfDAJp0YIfbT4fIK1oZ2R20tRX3xFCvjIS 数据：{} | 2016/10/26 15：02：30.161

3毫秒后，由于“陈旧的文件句柄” 0xb，客户端上的进程CLIENT-B“读取”操作失败

controller_debug.log.2：2016-10-26 15：02：30,164; INFO-[CLIENT-B：0xb]：已完成e84e2064ead042099310af1bd44821c0，结果：失败| 阅读| /mnt/DIRSPLIT-node0.b27-1/JUyw481MfvsBHOm1KQu7sHRB6ffAXKjwIATlsXmOgWh8XKQaIrPbxLgAo7sucdAM/o6V266xE8bTaUGzk8YDMfDAJp0YIfbT4Z41 [errno：116] | 旧文件句柄| 142 | 数据：{} | 2016年10月26日15：02：30.160 controller_debug.log.2：2016年10月26日15：02：30164;错误 - 操作请仔细阅读文件JUyw481MfvsBHOm1KQu7sHRB6ffAXKjwIATlsXmOgWh8XKQaIrPbxLgAo7sucdAM / o6V266xE8bTaUGzk8YDMfDAJp0YIfbT4fIK1oZ2R20tRX3xFCvjISj7WuMEwEV41意外失败，由于过时的文件句柄

谢谢

Answer 1

这是完全可以预期的。在删除对象（无论是文件还是目录）之后，NFS规范对文件句柄的使用很明确。 第四部分明确地解决了这一问题。例如：

当删除文件系统对象时，持久文件句柄将变为陈旧或无效。当服务器出现一个永久文件句柄，该文件句柄引用一个已删除的对象时，它必须返回一个NFS4ERR_STALE错误。

这是一个常见的问题，它甚至在NFS FAQ的 A.10部分中都有它自己的条目，该条目指出ESTALE错误的常见原因是：

文件句柄是指已删除的文件。在服务器上删除文件后，客户端只有在尝试使用从上一个LOOKUP缓存的文件句柄来访问文件时，才会发现该文件。在另一个客户端上使用文件时，使用rsync或mv替换文件是一种常见的情况，会导致ESTALE错误。

预期的解决方案是您的客户端应用程序必须关闭并重新打开文件以查看发生了什么。或者，如常见问题解答所述：

...要从ESTALE错误中恢复，应用程序必须关闭发生错误的文件或目录，然后重新打开它，以便NFS客户端可以再次解析路径名并检索新的文件句柄。