由于 FUSE 元数据缓存,`bindfs --mirror=user1:user2:...` 是否已损坏?

由于 FUSE 元数据缓存,`bindfs --mirror=user1:user2:...` 是否已损坏?

https://bindfs.org/docs/bindfs.1.html

-m, --mirror=user1:user2:..., -o mirror=...

采用逗号或冒号分隔的用户列表,这些用户将自己视为所有文件的所有者。如果权限允许,此处未列出的用户仍然可以访问装载。

您还可以提供带有“@”前缀的组名称来镜像组的所有成员。这不会更改文件显示的组。

我怀疑这如何与文件元数据的 Linux 内核缓存(VFS inode 缓存)一起工作......

运气不好的话有可能见到“错误”的主人吗?或者是否bindfs正确使用 Linux 内核 FUSE 实现的某些功能,强制 VFS inode 缓存在每次用户空间访问时重新获取 inode 所有权详细信息?

FUSE 内核默认每 3 秒从用户空间 FUSE 进程刷新一次 inode 属性。这可以通过 fuse.conf 文件中的 fuse.attr.timeout 参数进行调整。fuse.attr.timeout 参数指定在内核中刷新 inode 属性的时间间隔,可用于最大限度地减少刷新缓存所需的时间。

https://maprdocs.mapr.com/home/AdministratorGuide/MapRfusePOSIXClient-TuneCache.html

attr_超时=T

缓存文件/目录属性的超时(以秒为单位)。默认值为 1.0 秒。

http://man7.org/linux/man-pages/man8/mount.fuse.8.html

答案1

bindfs 确实可以处理这个问题。

https://github.com/mpartel/bindfs/blob/1.13.9/src/bindfs.c#L2248

/* We need to disable the attribute cache whenever two users
   can see different attributes. For now, only mirroring can do that. */
if (is_mirroring_enabled()) {
    fuse_opt_add_arg(&args, "-oattr_timeout=0");
}

我不确定如何准确地attr_timeout转换为内核索引节点缓存的行为。但我认为类似的问题适用于任何网络文件系统,它希望能够重新验证 inode 详细信息,以防它们在文件服务器上发生更改。

相关内容