3

有没有办法在非只读文件系统中安全地使用非零超时？我似乎找不到一个。几个反例：

示例一（非零负输入超时）：

  1. 应用程序调用 stat() 并获得 ENOENT；
  2. 调用 create();
  3. 调用 stat()，期待成功，但由于负输入超时而获得 ENOENT，因此得出 FS 损坏/不一致/等结论。

示例二（非零 attr 超时）：

  1. 应用程序调用 utimes();
  2. 调用 stat()，但获取过时的值并得出 FS 损坏/不一致/等结论。

我无法为正输入超时提出反例 - 似乎即使 lookup() 返回一些陈旧的 inode，文件系统仍然可以为稍后的 getattr() 调用返回 ENOENT。

但是上面的两个例子呢？

4

1 回答 1

3

仅供参考，在FUSE 邮件列表上发布了相同的问题。

这是Kyle Lippincott关于为什么非零超时有效的答案：

如果 create() 通过内核，它会使负输入超时无效。如果创建发生在外部，则超时仍然有效。

当非零超时成为问题时，引用 Goswin von Brederlow 的话：

缓存只有在您实现基于磁盘的文件系统时才能正常工作，其中只有熔断进程可以更改元数据并且所有访问都只能通过熔断进行。任何可以在不通过 fuse 的情况下更改底层文件系统的覆盖文件系统都可能会遇到不一致。

因此，如果您正在构建一个允许多个主机更改数据的网络文件系统，您可能会遇到非零超时问题。

于 2014-02-08T14:30:45.350 回答