FUSE 文件系统操作
如何循环 FUSE 文件系统超级块中的索引节点？该文档对此没有任何说明。
How do I loop over the inodes in the superblock of a FUSE filesystem? The documentation specifies nothing about this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以通过调用
nftw()在活动 FUSE 实例的挂载点。您提供的回调将获得路径和struct stat对于文件系统中的每个条目。您可以通过对返回路径的系统调用与相应的 inode 进行交互。You can iterate over the visible ones (those with entries), by calling
nftw()at the mount point of an active FUSE instance. The callback you provide will be given the path andstruct statfor each entry in the filesystem. You can interact with the corresponding inodes via systems calls to the returned paths.FUSE 不是文件系统，也不包含传统的 inode。最好将其视为 UNIX 文件系统 API 提供的相反实现。例如，当您打开文件时，会生成文件打开系统调用。然后内核接受该系统调用并返回一个文件。
FUSE 的作用是从内核将该系统调用重定向到返回用户空间的 FUSE 应用程序。然后应用程序决定如何响应该系统调用并向内核返回一些内容。然后内核将该响应传递回原始调用应用程序。
在许多情况下，当您使用 FUSE 挂载某些内容时，您并不是在挂载物理介质。当您在 FUSE 文件系统中打开文件时，它可能会在真实文件系统的某个位置创建一个临时文件，将数据复制到该文件，然后将 FUSE 文件上的大多数文件操作调用重定向到它创建的临时文件。
大多数 FUSE 应用程序实现 stat，并提供真实 INODE 结构将具有的大部分信息，但是，该信息通常不具有指向它的指针方面。
从技术角度来看，您可以在 FUSE 中实现类似 EXT3 的功能，它将 EXT3 文件系统作为挂载参数进行挂载。在这种情况下，您可以想象真实的 INODES，可能带有实际的 INODE 指针。然而，EXT3 的实现可能相当不受欢迎，因为每个文件系统调用都涉及从用户空间到内核，再到 FUSE 用户空间，再到内核，再到 FUSE 用户空间，再到内核，最后返回到您的应用程序。 FUSE 对于性能不重要的文件系统更有意义。
FUSE is not a file system, and does not contain traditional inodes. It is better to think of it as implementing the reverse of what the UNIX file system API provides. For instance, when you open a file, you generate a file open system call. The kernel then takes that system call and returns a file.
What FUSE does is from the kernel it redirects that system call to the FUSE application which is back in user space. The application then decides how to respond to that system call and returns something to the kernel. The kernel then passes that response back to the original calling application.
In many cases, when you mount something with FUSE, you are not mounting a physical medium. When you open a file in a FUSE file system, it is probably going to create a temporary file on a real file system somewhere, copy data to that file, and then redirect most file operation calls on the FUSE file to the temporary file it created.
Most FUSE application implement stat, and provide most of the information that a real INODE structure would have, however, that information would not in general have a pointer aspect to it.
From a technical standpoint, you could implement something like EXT3 in FUSE, where it would take as a mount argument the EXT3 file system to mount. In that case, you could imagine real INODES, potentially with actual INODE pointers. However, that implementation of EXT3 would probably be fairly unpopular as every file system call would involve going from userspace to kernel to FUSE userspace to kernel to FUSE userspace to kernel and then finally back to your application. FUSE makes a lot more sense for file systems where performance is not important.