F* file system：绕过操作系统内核，直接读取 SSD 进行文件搜索

背景

在 Linux 和 macOS 等现代操作系统中，文件搜索通常依赖于操作系统内核提供的虚拟文件系统（VFS）接口。标准的命令行搜索工具（如 grep 或 ripgrep）通过标准的系统调用（如 read()）从内核缓冲区中获取数据。这种方式虽然稳定且兼容性好，但在处理海量文件或特定文件系统结构时，内核的缓存机制、权限检查以及抽象层可能会引入额外的开销。

近期，一个名为 F file system*（简称 ffs）的开源命令行工具在 Hacker News 上引发了关注。这是一个仅约 1.5k 行 C 代码编写的实验性工具，其核心设计理念是“绕过操作系统内核”，直接读取磁盘块设备（raw device nodes）来执行文件搜索。尽管作者自嘲其“在实际生产中几乎无用”，但其技术实现展示了底层存储与文件系统解析的极致优化，提供了一种不同于传统 VFS 路径的搜索范式。

核心内容

F file system* 是一个基于 C 语言开发的命令行工具，旨在通过直接读取磁盘原始数据来搜索文件内容，类似于 grep 的功能，但底层机制完全不同。

1. 工作原理：绕过 VFS 与内核缓存

传统搜索工具通过操作系统的虚拟文件系统（VFS）层读取文件，数据往往先经过内核的页缓存（Page Cache）。而 ffs 使用 pread 系统调用直接对块设备（block device）进行读取。这意味着它完全绕过了 VFS 和缓冲 read() 路径，直接解析磁盘上的二进制数据块。

• 性能特性：由于不依赖内核缓存，ffs 在搜索较小或已缓存的目录时可能比 ripgrep 慢。然而，随着搜索文件数量的增加，当内核缓存耗尽、必须从物理磁盘读取数据时，ffs 的速度会显著超越 ripgrep。这种设计旨在证明：在某些场景下，内核 VFS 层本身已成为性能瓶颈。
• 并行处理：工具利用 OpenMP 将负载分散到所有 CPU 核心上，以最大化并行搜索效率。

2. 支持的文件系统与实现细节

ffs 并未依赖操作系统内置的文件系统驱动，而是手动实现了针对特定文件系统的解析逻辑。目前主要支持以下几种文件系统：

• Btrfs（B-tree File System）：
  • 这是 ffs 支持最复杂的文件系统。Btrfs 是一种高效的 B 树结构存储，具有写时复制（Copy-on-Write, CoW）特性。
  • 局限性：由于 B 树结构在文件更新时会修改超级块（Superblock），如果 ffs 读取了超级块后内核更新了树结构，之前的读取结果将失效。
  • 解决方案：可以通过 fsfreeze 冻结文件系统，或创建独立的分离卷（detached volume）来避免此问题。
• Journaling File System（日志文件系统）：
  • 支持原地写入（in-place writing）且无写时复制的日志文件系统。这是 ffs 表现最好的场景。
  • 局限性：可能无法看到最近的文件写入，因为内核可能将更新暂存在缓存中并延迟写入磁盘。用户需手动执行 sync 命令强制同步。
• APFS（Apple File System）：
  • Apple 的专有文件系统，通过逆向工程实现支持。
  • 限制：受限于 Apple 的安全策略，无法在主磁盘上直接运行。

3. 权限与安全要求

• Linux：通常只需要在读取原始设备节点（如 /dev/rdisk* 或 /dev/sda）时需要 sudo 权限。搜索镜像文件（如 .iso 或 .dmg）则不需要 elevated permissions。
• macOS：由于系统完整性保护（SIP, System Integrity Protection）机制，即使使用 sudo 也无法访问主磁盘的超级块。用户必须禁用 SIP 才能在主磁盘上运行 ffs。如果用户使用如 yabai 等项目，SIP 可能已经处于禁用状态。

4. 实用功能与测试方法

尽管在主磁盘上运行受限，ffs 提供了无需挂载即可搜索分离卷的功能：

• 直接搜索镜像文件：用户可以指定原始字节路径和文件系统类型，直接搜索 .dmg、.iso 等未挂载的卷。
  • 示例命令：ffs "<QUERY>" /path/to/volume.dmg apfs
  • 这使得搜索应用安装程序（本质上是分离的卷）变得非常便捷，无需先挂载。
• 二进制文件检测：工具能够自动检测并跳过二进制文件，专注于文本内容搜索。

5. 性能对比数据

作者提供了在 btrfs 挂载驱动器上的基准测试，对比 ffs 与 ripgrep（使用 -F --no-heading -H -n --no-ignore --hidden --one-file-system --no-messages 参数以输出相同结果）：

| 目录 | 文件数量 | ffs 耗时 | ripgrep 耗时 | 备注 | | :--- | :--- | :--- | :--- | :--- | | repos | 631k files | 5.505s | 4.813s | 小文件集，rg 略快 | | dev | 1.50M files | 18.413s | 25.673s | 中等规模，ffs 开始领先 | | home | 3.25M files | 36.205s | 74.690s | 大规模文件集，ffs 显著更快 |

值得注意的是，ripgrep 使用了更先进的基于 SIMD 的匹配器和文件遍历算法，而 ffs 仅由约 1.8k 行 C 代码构成。在大规模文件搜索中，ffs 直接读取磁盘的优势压倒了 ripgrep 的软件优化优势。

6. 编译与依赖

• 依赖库：需要 libzstd（用于 btrfs 支持）和 openmp。
• 编译命令：

  make ffs
  ffs --help
  

关键要点

• 直接磁盘访问：ffs 绕过操作系统内核的 VFS 和页缓存，直接使用 pread 读取块设备，旨在消除内核抽象层带来的性能开销。
• 规模效应显著：在文件数量较少或数据已缓存时，ffs 可能慢于 ripgrep；但在大规模文件搜索（数百万文件）且缓存失效时，ffs 速度远超 ripgrep。
• 文件系统支持有限：仅支持手动实现的特定文件系统（如 Btrfs、特定日志文件系统、逆向工程的 APFS），不支持所有 Linux 文件系统。
• macOS 限制严格：受限于 SIP（系统完整性保护），在 macOS 主磁盘上运行需禁用 SIP；但可无权限直接搜索 .dmg 等镜像文件。
• 数据一致性挑战：在 Btrfs 等写时复制文件系统中，并发更新可能导致读取无效，需通过 fsfreeze 或分离卷解决；在日志文件系统中可能因内核缓存延迟而漏读最新写入。
• 技术演示意义大于实用：作者承认该工具“几乎无用”，但其核心价值在于证明内核 VFS 在特定极端场景下可能成为性能瓶颈，并展示了底层存储解析的可行性。
• 轻量级实现：整个核心功能仅由约 1.5k - 1.8k 行 C 代码实现，体现了极高的代码密度和技术技巧。

意义与影响

F file system* 的出现虽然不具备广泛的商业应用价值，但在技术社区和系统编程领域具有重要的启示意义：

1. 挑战传统 I/O 模型：