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

Question

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

在某些情况下，某些进程会删除文件，而某些其他进程会尝试从中读取文件，但我收到“Stale file handle”错误（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 / o6V266xE8bTaUGzk8YDMfDAJp0YIfbT4fIK1oZ2R20tRX3xFCvjISj7WuMEwEV41   |数据：{} | 2016/10/26 15：02：30.156

客户端0x1上的

流程CLIENT-A已成功删除：

  

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

3毫秒后，客户端0xb上的进程CLIENT-B由于“过时文件句柄”而无法“读取”操作

  

controller_debug.log.2：2016-10-26 15：02：30,164; INFO -   [客户-B：0xb]：完成e84e2064ead042099310af1bd44821c0，结果：   失败了|读|   /mnt/DIRSPLIT-node0.b27-1/JUyw481MfvsBHOm1KQu7sHRB6ffAXKjwIATlsXmOgWh8XKQaIrPbxLgAo7sucdAM/o6V266xE8bTaUGzk8YDMfDAJp0YIfbT4fIK1oZ2R20tRX3xFCvjISj7WuMEwEV41   | [错误号码：116] |过时的文件句柄| 142 |数据：{} | 2016年10月26日   15：02：30.160 controller_debug.log.2：2016-10-26 15：02：30,164;错误 -   操作在文件上显示FAILED UNEXPECTEDLY   JUyw481MfvsBHOm1KQu7sHRB6ffAXKjwIATlsXmOgWh8XKQaIrPbxLgAo7sucdAM / o6V266xE8bTaUGzk8YDMfDAJp0YIfbT4fIK1oZ2R20tRX3xFCvjISj7WuMEwEV41   由于Stale文件句柄

由于

Answer 1

这完全是预期的。 NFS规范清楚地表明在删除对象（文件或目录）后使用文件句柄。 Section 4明确地解决了这个问题。例如：

  

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

这是一个常见问题，甚至在NFS FAQ的A.10节中也有自己的条目，其中说明了ESTALE错误的一个常见原因是：

  

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

预期的解决方案是您的客户端应用必须关闭并重新打开该文件以查看发生的情况。或者，正如常见问题解答所说：

  

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