熔断器开放系统调用机制

Question

当从程序调用open系统调用时，为了在FUSE托管目录中创建一个空文件(用O_WRONLY | O_CREAT | O_TRUNC)，将执行FUSE文件系统实现中的以下功能：

1. getattr (返回错误，因为文件不存在)
2. create
3. fgetattr

我的问题是：

这些函数调用对Linux中的所有文件系统(包括本地系统，如ext4)是通用的，还是对内部行为的融合？

当strace-ing程序时，我只能看到一个open系统调用。

Answer 1

经过几天的研究和盯着Linux内核和FUSE源代码，我明白了发生了什么。

首先，我必须指出，在执行release系统调用时，fgetattr后的open不是在执行，而是在调用close时执行的。所以我修改了我的问题来删除它。

嗯，我的主要问题是strace向我显示了对open系统调用的调用，但是FUSE程序日志显示执行了三个函数。因此我对其他文件系统提出了疑问。

在Linux内核文档中，我们可以看到详细解释的内核VFS：

要查找inode，需要VFS调用父目录inode的lookup()方法。此方法是由inode所在的特定文件系统实现安装的。一旦VFS有了所需的dentry (因此也就是inode)，我们就可以做所有那些无聊的事情，比如打开(2)文件，或者stat(2)。

在FUSE文件系统中，这意味着低级API中的lookup调用，或者高级API中的getattr (因为inode路径转换由lib引信处理)。用户代码。其他系统调用(如mkdir或带有O_CREAT标志的open )也需要lookup，在本例中，在执行任何操作之前都需要确认负dentry。第1点已解决。

您得到的dentry不应该有inode (也就是说，它应该是负的dentry)。

与ext4一样，在内核中实现的文件系统也会将它们的函数执行到lookup。但是你不能用像strace这样的通用工具从外部看到它们(你需要一些像内核鲨鱼之类的东西，很棒的东西)。

参见ext4查找函数 (我正在运行Linux3.13内核)

点3的fgetattr函数调用更多地与lib引信内部关联。我不知道确切的原因，但是lookup是在执行mkdir或create之类的函数之后由lib引信执行的。请记住，lookup是高级API中的getattr (或创建文件的fgetattr )。我认为这是由于文件/目录属性检查。

您可以在Lib引信源代码上看到它对create函数的作用。

奖励:记住FUSE使用了一个文件属性(和条目)缓存。如果将stat挂载选项设置为0秒，某些调用(如getattr )会将两个getattr提升到高级API。