Bil*_*ilk 4 c linux filesystems fuse
当open从程序调用系统调用时，要O_WRONLY | O_CREAT | O_TRUNC在 FUSE 管理目录中创建一个空文件（带有），将执行我的 FUSE 文件系统实现中的以下函数：
getattr （返回错误，因为文件不存在）createfgetattr我的问题是：
这些函数调用对于 Linux 中的所有文件系统（包括像 ext4 这样的原生文件系统）是通用的，还是 FUSE 内部行为？
当strace-ing程序，我只能看到一个open系统调用。
经过几天的研究和盯着 Linux 内核和 FUSE 源代码，我明白发生了什么。
首先，我不得不说releaseafterfgetattr不是在执行open系统调用时执行，而是在调用close. 所以我编辑了我的问题以将其删除。
好吧，我的主要问题是strace向我显示了对open系统调用的调用，但是我的 FUSE 程序日志显示执行了三个函数。因此我的问题是关于其他文件系统。
在Linux 内核文档中我们可以看到内核 VFS 的详细解释：
查找inode 需要VFS 调用父目录inode 的lookup() 方法。此方法由 inode 所在的特定文件系统实现安装。 一旦 VFS 拥有所需的 dentry（以及 inode），我们就可以执行所有这些无聊的事情，例如 open(2) 文件或 stat(2)
在 FUSE 文件系统中，这意味着lookup调用低级 API，或调用getattr高级 API（因为 inode-path 转换由 libfuse 处理）。用户地代码。其他系统调用，如mkdir或open带O_CREAT标志，也需要lookup, 在这种情况下，在做任何事情之前确认否定的 dentry。第 1 点已解决。
你得到的 dentry 不应该有一个 inode（即它应该是一个负的 dentry）。
在内核中实现的文件系统，如 ext4，也执行它们的功能lookup。但是你不能用常用工具从外面看到它们strace（你需要像 kernelshark 这样的东西，很棒的东西）。
请参阅ext4 查找功能（我正在运行 Linux 3.13 内核）
第fgetattr3 点的函数调用更多地与 libfuse 内部相关。我不知道确切的原因，但是lookup在执行诸如mkdiror 之类的函数后，libfuse 会执行 a create。请记住， alookup是高级 API 中的a getattr（或fgetattr用于创建的文件）。我认为这是由于文件/目录属性检查。
您可以在创建函数的libfuse 源代码中看到它的运行情况。
奖励：请记住 FUSE 使用文件属性（和条目）缓存。如果您将挂载选项设置为 0 秒，一些调用stat会提升两个getattr到高级 API -o attr_timeout。