filesystems - 如何在 FUSE/OSXFUSE 底层 API 中使用 entry_timeout 和 attr_timeout？

Question

有什么方法可以在非只读文件系统中安全地使用非零超时？我似乎找不到一个。几个反例:

示例一(非零负输入超时):

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

示例二(非零属性超时):

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

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

但是上面两个例子呢？

Answer 1

仅供引用，同样的问题发布在FUSE mailing list .

这是 answer from Kyle Lippincott为什么非零超时有效:

If the create() goes through the kernel, it invalidates the negative entry timeout. If the create happens externally, then the timeout still holds.

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

Caching only works correctly if you implement a disk based filesystem, one where only the fuse process can alter metadata and all access goes only through fuse. Any overlay filesystem where something can change the underlying filesystem without going through fuse can run into inconsistencies.

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