用户空间程序可以与具体文件系统（不是 VFS）交互吗？我得到的是，VFS 允许 linux 同等对待所有文件系统，并为用户空间提供抽象的 api。
我想要实现这样一个条件：自定义文件系统应该能够提供一个 API，用于在用户空间可用的页面级别上读取、写入和擦除磁盘（SSD）。
为此，我需要一种方法来实现绕过 VFS 与具体文件系统的交互。
答案1
文件系统交互的唯一入口点是系统调用机制，而系统调用机制又严重依赖（如果不是唯一的话）VFS。
如果有人想要创建一个不依赖于 VFS 的文件系统，那么该人将被迫实现一组新的 I/O 系统调用，这些调用将直接与 Linux 块级别交互。
这既不优雅也不便携。除了实现、调试和维护是一场噩梦之外，这个自定义文件系统只能由使用这组自定义系统调用的应用程序访问。这种方法将任何可移植性的概念抛到了九霄云外。
因此，回答您的问题：是的，可以通过实现一组新的系统调用来实现，但此类文件系统的唯一用户空间客户端将是您自己的应用程序。对于比这更便携的东西，您必须使用 VFS。
编辑：
我看到你的先前的问题关于为 SSD 实施高性能键值存储系统，我相信这促使您考虑这种方法。我想补充两点：
- VFS 是不是一个瓶颈。它将 I/O 操作非常有效地路由到 Linux 块级别。
- 需要内核修补（代码质量有问题）的应用程序的可用性极低。除非您明确编写此系统供自己个人使用，否则我建议在尝试优化内核内的内容之前探索其他可能性。
答案2
除了“在磁盘上擦除”（即 ioctl()）之外，它看起来很像：
- 读/写块设备上的页面
- 读/写给定文件的页面
你们都可以使用 lseek + 以适当的页面大小读/写来执行此操作。
（如果您希望在一个系统调用上提供所有内容，您可以执行 pread/pwrite，但它是等效的）
答案3
继Linux 上的低级磁盘 I/O，您可以实现自己的代码来使用直接访问块设备的程序来访问文件系统。这很可能比内核中的文件系统驱动程序慢（通过 VFS 层访问 - 这就是 VFS 层的作用）。这是可能的，并且对于某些用例很有用（例如取证或访问内核不支持的文件系统类型），但对于您的用例来说这是错误的方法。