GeminiFS: A Companion File System for GPUs (FAST'25) Shi Qiu, Weinan Liu, Yifan Hu, Jianqin Yan, Zhirong Shen, Xin Yao, Renhai Chen, Gong Zhang, Yiming Zhang XMU NICE Lab, SJTU, Huawei Theory Lab Managing Scalable Direct Storage Accesses for GPUs with GoFS (SOSP'25) University of Illinois Urbana-Champaign |
引言
过去十年，英伟达股价因加密货币和生成式 AI 的爆发经历了两次飙升。AI大爆发后，美国对中国封锁高端 GPU 芯片，AI算力的重要性达到了地缘政治的高度。对于 AI 和科学计算等需求并行计算的应用，GPU 在吞吐、能效和可扩展性上对通用 CPU 形成系统性优势。GPU 的角色正在从 CPU 的协处理器，逐渐转变为系统的计算中心，开始挑战并部分替代 CPU 在数据中心长久以来占据的核心地位。
然而，一个根本性瓶颈也随之浮现——存储墙（Storage Wall）。GPU 拥有数千上万个核心，计算吞吐量高，但其显存（HBM）容量通常为几十GB，而数据工作集可达几十TB。GPU 在计算过程中往往需要依赖 CPU 频繁从外部存储（如 SSD）读取与写回数据，形成 I/O 瓶颈。
为减少 CPU/GPU 之间的同步开销和提升 GPU 访问存储的效率，业界探索了 GPU 直接访问甚至控制存储设备的技术路径，其中以 GPUDirect Storage 和 BaM 为代表（详细介绍参见下一章）。前者在 GPU 与存储之间建立了直接的数据通路，后者进一步在控制面绕过 CPU 直接向 SSD 发起 I/O。然而，前者依然在控制面依赖 CPU，后者要求 GPU 管理 SSD 裸设备，应用开发负担重，并面临数据共享、一致性和安全性等挑战。
令人惊喜的是，今年的系统领域顶会上发表了两篇代表性论文——来自于厦门大学/上海交通大学的 GeminiFS (FAST 2025) 和来自于伊利诺伊大学香槟分校的 GoFS (SOSP 2025)，展示了另一条充满想象力的路径——面向 GPU 构建高效可扩展的文件系统。它们为 GPU 应用保留通用的文件抽象和编程接口，提供高效直接的存储访问。
本文对两项论文工作进行技术解读和评述，总体内容框架如下。
-
背景介绍。对比 CPU 与 GPU 的计算架构与典型应用场景，介绍现有的 GPU 直接访问存储方案 GDS 与 BaM。
GeminiFS (FAST'25) 和GoFS (SOSP'25)论文解读。GeminiFS为 GPU 设计了一个由 CPU 主管的伴生型文件系统；GoFS则绕过 CPU 构建了一个由 GPU 主管的文件系统。本章介绍这两项工作的动机、观察、设计和评估。
论文评述。GeminiFS 尽管对 GPU 应用负载特征具有较强的假设限制，但它是一个“脚踏实地”的务实选择，为GPU文件系统开辟出了一条可行的道路。相比而言，GoFS 给我们提供了“仰望星空”的美丽想象，但笔者从论文看不出来基于当前架构构建GPU原生通用的文件系统这条路径是切实可行的。
1. 背景介绍
（1）CPU 与 GPU 计算架构对比
CPU 一直以来是计算机的“大脑”，设计初衷是通用性处理器，其特点是低延迟和强控制。如下图所示，它拥有少量强大且复杂的计算核心，每个核心配有较大容量的L1/L2/L3缓存，擅长处理复杂的指令和逻辑分支，进行快速的任务切换和响应。总体上，CPU 是为低延迟和处理复杂串行任务而设计的“指挥官”，典型应用包括操作系统（含文件系统）、数据库、办公软件等。
GPU 最初是为了加速图形渲染而生，因为渲染屏幕上的数百万个像素点是一个典型的高度并行任务。后来，人们发现其架构也适合其它并行计算场景，催生了 GPGPU (通用计算图形处理器) 的概念。它拥有数千个简单且高效的流处理器计算核心，配备较小容量的缓存和大容量的高带宽内存。GPU 的控制逻辑较为简单，难以支持复杂的程序处理，如分支预测和乱序执行等。总体上，GPU 则是为高吞吐量、处理大规模并行任务而设计的“军团”，典型应用包括图形渲染、AI（大量矩阵运算）、科学计算、加密货币等。
现代计算的趋势不是用 GPU 取代 CPU，而是将它们更紧密地结合在一起形成“异构计算”平台。英特尔大约在 2010 年就开始在 CPU 中集成 GPU，而英伟达在 2022 年推出了面向 AI 基础设施和高性能计算的基于 ARM 的数据中心专属 CPU。同时，FPGA、DPU、XPU 等不同形态的计算加速器方兴未艾，行业正转向以异构计算为基础的技术新生态。
（2）现有的 GPU 直接访问存储方案 GDS 与 BaM
GDS (GPUDirect Storage) 是 NVIDIA 推出的一项旨在加速 GPU 数据加载的技术，其核心是建立一个从 NVMe 存储到 GPU 显存的直接数据通路。在传统方案中（如下图中左侧的 GPUFS、Dragon），数据从存储读取需要先拷贝到 CPU 内存，再由 CPU 拷贝到 GPU 显存 HBM，这个过程被称为“bounce buffer”，会产生不必要的延迟和 CPU 资源消耗。
GDS 技术绕过 CPU 内存作为中转站，允许存储设备的 DMA 引擎直接将数据通过 PCIe 总线传输到 GPU 显存中。GDS 本质上仍是一个 CPU-centric 方案，虽然数据路径是直接的，但 I/O 请求的发起和控制流仍然依赖 CPU。GPU 应用需要数据时，必须由 CPU 端的代码调用 GDS 库（如 cuFile API）来发起 I/O 操作。因此，当 GPU 的海量线程高并发请求数据时，CPU 软件栈开销、CPU 与 GPU 之间的同步开销容易导致性能瓶颈。
英伟达与伊利诺伊大学香槟分校团队在 ASPLOS 2023 顶会论文上提出了 BaM (Big accelerator Memory) 技术，它是第一种 GPU-centric 存储访问方案。如下图右侧所示，它在 GPU 侧实现了 NVMe 协议，在显存 HBM 中直接分配和管理 NVMe SQ/CQ I/O 队列，因此 GPU 线程可以像 CPU 一样自行构造 NVMe I/O 命令，将其写到 SQs 并“按门铃”通知 NVMe 控制器来取任务。当 I/O 操作完成后，NVMe 控制器会将完成信息写回 GPU 显存中的 CQs，GPU 线程通过轮询该队列即可获知结果。
整个 I/O 过程不再需要 CPU 参与，消除了 CPU-GPU 间的通信和同步开销。但 BaM 的代价是它不提供文件系统抽象，应用开发者需要直接管理裸盘和数据，例如实现一个类似于 SPDK BlobFS 的用户态文件系统，而且无法在 GPU 和 CPU 之间共享数据，面临访问控制和崩溃一致性等挑战。
2. GeminiFS (FAST'25) 论文解读
（1）研究动机
Unfortunately, building such a general GPU file system is prohibitively difficult, since GPUs are naturally unsuitable for running a stateful software such as a file system that requires complex metadata maintenance.
GeminiFS (FAST 2025)
作者选择为 GPU 设计一个与 CPU 文件系统共存的轻量化文件系统，即GPU 访问的文件能够被 CPU 管理。该方法面临以下四大挑战。
元数据同步：如何在主机 CPU 和 GPU 的文件系统间高效、安全地同步元数据，避免引入新的通信瓶颈。
设备驱动限制：现有的 NVMe 驱动不允许 CPU 和 GPU 同时为同一设备建立独立的控制平面（I/O 队列），阻碍了 GPU 的直接 I/O 访问。
GPU 页缓存效率：文件系统仅能运行在 GPU 的非特权状态，因此只能在一个 GPU 进程的内存空间内分配页缓存（page cache），阻碍了多进程多 GPU 共享使用缓存（如多个进程同时访问一个文件时只能各自缓存一份文件数据），因此需要实现可跨进程共享的页缓存。而且，为保障数据一致性，并发访问缓存会引入严重的锁竞争，不能发挥 GPU 高并行特性。
GPU 编程复杂性：如何将底层复杂的元数据管理、与主机端文件系统和 NVMe 驱动的交互等细节进行封装和抽象，为开发者提供简洁易用的编程接口。
（2）GPU 应用存储负载观察
论文分析 GPU 应用（如 DNN、GNN 和 LLM）的存储访问负载（如下表所示），发现以下几个重要特征，它们是 GeminiFS 设计的前提和基础。
追加写和只读：长期数据（如模型权重、KV-Cache、训练输入数据）的典型访问模式是在生成阶段追加写入，之后变为只读；短期数据（如中间结果）不需要持久化和一致性保障。
访问模式可预测：大部分数据访问具有可预测性，例如 DNN 训练过程的数据访问模式和大小可以通过分析模型设计和迭代次数预测。
数据需跨进程共享：模型权重、KV-Cache 等数据需要被多个 GPU 进程共享，以支持并行训练或多路推理。
这些观察意味着，对于 GPU 访问的场景，不需要在 GPU 端实现一个功能完备、支持任意修改的复杂文件系统。一个轻量级的、针对特定模式优化的方案是可行的。例如，可预测性和仅追加写简化了元数据管理，避免了在 GPU 端进行复杂的元数据分配和同步。
（3）设计方案
GeminiFS 的核心思想是构建一个与主机文件系统“伴生 (Companion)”的轻量级 GPU 文件系统。主机 CPU 负责 GPU 文件的创建和删除、页缓存配置等操作，以及文件系统元数据管理工作；而通过在文件中嵌入元数据使得 GPU 能够获取文件的 NVMe 存储地址并读写文件，GPU 只会修改文件内嵌的元数据，待 GPU 关闭文件后，由 CPU 从持久化的 GPU 文件中获取元数据修改并同步到本地元数据。设计架构图和具体技术点介绍如下。
(a) 嵌入元数据的自描述文件格式
主机 CPU 负责文件系统元数据管理，保障安全性和一致性。当 GPU 执行文件操作修改元数据时，与 CPU 进行元数据同步的性能开销大，违反设计初衷。为此，利用 GPU 应用的存储负载的可预测性（如文件大小可预测），由 CPU 为 GPU 应用创建指定大小的文件和预分配连续的存储空间（GVDK File），在其中嵌入必要的元数据，包括文件类型、大小、文件数据块的 NVMe 存储地址（Mapping）、per-block dirty bitmap。
内嵌 mapping 信息是考虑到 GPU 难以高效执行地址转换操作，如 ext4 中的 extent tree 查询，该信息使得 GPU 能够直接获取文件存储地址并发起 I/O 请求。dirty bitmap 用于指示某个数据块/存储地址是否被 GPU 写过，待 GPU 关闭文件后 CPU 将该元数据同步到本地元数据。
(b) CPU/GPU 共享 NVMe 驱动 (SNVMe)
论文扩展了现有的 Linux NVMe 驱动，CPU 依然负责管理和初始化 NVMe 设备，但支持同时在 CPU 内存和 GPU 显存中分别创建独立的 NVMe I/O 队列 SQs 和 CQs，其中 GPU 端向 SQ 提交请求和轮询 CQ 完成请求的方式与 BaM 相同。
(c) GPU 专用的页缓存
CPU 端 SNVMe 驱动包含一个 GPU 页缓存管理模块，负责为 GPU 打开的文件配置页缓存，并支持跨进程共享访问缓存。当一个文件被某个 GPU 应用进程第一次打开时（非 direct 模式），它负责为该文件分配 GPU 显存初始化页缓存，并维护一个全局的内存句柄指向该缓存。当另一个进程打开该文件时，它可以通过内存句柄共享访问其缓存，避免在该进程的内存空间内冗余创建页缓存。
为应对 GPU 的高并发访问，页缓存采用 Warp 级别（而非更细粒度的线程级别）的锁来减少锁争用，并使用哈希表和双向链表结合的索引结构提供快速的插入、删除和查询操作。另外，页缓存支持预取来最大化利用 NVMe SSD 带宽。
(d) libGemini 编程库
GeminiFS 为用户提供了一套精简的 POSIX 语义的文件操作 API，如下表所示。其中，Geminifs_init、G_open、G_close 由主机 CPU 主导执行。Geminifs_init 负责初始化 GPU 显存中的 NVMe 队列；G_open 创建 GPU 可访问和内嵌元数据的 GVDK File，并配置页缓存；G_close 释放文件所使用的 GPU 显存资源，从文件内嵌元数据同步修改到本地元数据。
(4) 实验评估
实验平台与配置：GeminiFS 的实现包括约 2000 行的 NVMe 驱动修改和约 3000 行的 LibGemini。服务器包含 64 核 Intel Xeon CPU、512GB DRAM、带 80GB HBM 显存的 NVIDIA GPU、Intel Optane 5800X NVMe SSD，文件系统为 EXT4。在 NVMe I/O SQ 和 CQ 队列方面，为主机 CPU 分配 64 对，GPU 分配 32 对。
对比方案与测试负载：对比 GPUfs（采用 CPU 内存中转的 I/O 方式）、GDS、BaM 三种方案。测试负载包括微基准测试（如不同并发度下的 4KB 随机读写）和真实应用测试（如 LLM Training）。
主要测试结论：
与 CPU-centric GDS 和 GPUfs 相比，GeminiFS 在高并发的读负载下实现了 6+ 倍和 7+倍的带宽，延迟大幅降低（降低 79.6% - 90.9%）。其性能与无文件抽象的 BaM 方案非常接近（带宽仅低 4.6%），但提供了关键的文件系统功能。
GeminiFS 的页缓存带宽可以超过 640 GB/s，远超单个 NVMe 设备带宽，能有效加速文件数据访问。
在 LLM 训练中，GeminiFS 将 checkpoint 写入时间减少了高达 85%。在 I/O 密集型的 activation offloading 场景下，相比于 GDS，训练时间缩短了 91%，使存储扩展方案的性能更接近纯内存方案。
3. GoFS (SOSP'25) 论文解读
（1）研究动机
针对 GPU 访问存储面临的性能瓶颈问题，上述工作 GeminiFS (FAST'25) 提出为 GPU 构建由 CPU 主管的伴生型文件系统，该方法的设计前提是假设 GPU 应用的存储 I/O 负载具有可预测性和以只读为主。然而，很多 GPU 应用（如智能查询、图计算、GNN 训练、大模型 RAG）的存储负载可能难以准确预测，且包含新的写入。
该论文旨在构建一个由 GPU 主管的、通用的、可扩展性的文件系统。它绕过 CPU 的控制和中转，将文件系统的元数据管理和 I/O 操作等关键逻辑都放到 GPU 上运行，支持 GPU 应用以文件接口对 NVMe 存储进行直接的高并发访问。为实现以上目标，面临的关键挑战如下。
支持高并发的元数据访问和 I/O 机制：传统文件系统的元数据结构设计是面向 CPU 的串行或有限并发执行的特点，不适合 GPU 的超高并发访问模式，存在严重的扩展性问题。另外，I/O 机制也应适配 GPU 的高并发特征。
保障数据一致性：设计目标包括兼容主机 CPU 访问同一个文件系统，因此需要在 GPU 和 CPU 之间保障数据一致性。同时，需要保障文件系统的崩溃一致性。
数据安全与保护：CPU 依赖特权环来隔离和保护操作系统内核免受用户应用程序的干扰，而 GPU 不提供该安全机制，因此需要设计新的内存隔离和文件访问权限控制机制。
（2）设计方案
如下图所示，GoFS 将文件系统的主体功能在 GPU 上以一个轻量级用户态守护进程（GoFS Daemon）的形式实现，包括元数据管理和 I/O 处理；GPU 应用通过 libgofs 库与该守护进程通信和访问文件系统；主机 CPU 端运行 GoFS Client，支持主机应用访问 GoFS。
针对上述挑战，GoFS 的主要设计如下。
元数据管理：采用与 F2FS 一样的日志结构存储布局，设计 GPU 友好的元数据结构，通过细粒度锁和批量化处理来支持高并发的 inode/dentry 访问、块地址分配、以及遍历操作。
Inode 访问：将 inode 粒度的互斥锁替换为细粒度的 file range lock，以支持多线程并发访问同一个文件。
dentry 访问：为加速文件路径解析过程，在 GPU 显存中设置 dentry 缓存并为其中的哈希表采用细粒度的 per-bucket lock。为提高大量文件的并发访问效率，引入 batched node 结构，记录同一个目录中同时打开的多个小文件，合并处理它们的元数据操作。
块地址分配：不像 F2FS 采用中心化的 block bitmap 来记录 free blocks，而是为 GPU 的每个 SM 核心分配和维护独立的 free segments 及它们的 block bitmaps（block 和 segment 大小分别为 4KB 和 2MB）。另外，聚合处理同一个线程块中多个线程的块地址分配操作，减少 per-SM bitmap 竞争。
树结构遍历：文件系统采用树结构索引文件数据块，借鉴图遍历算法，采用按层同步的并发遍历机制。
I/O 机制：创建尽可能多的 NVMe SQ/CQ 队列（受限于 SSD 硬件配置），在 SM 核心之间平均分配。值得注意的是，GoFS 选择不设置 page cache，因为 GPU 应用访问的数据集通常非常大，难以全部缓存，而且常见的访问模式是不存在时间局部性的流式访问。因此，数据会直接从 SSD 传输到应用程序的缓存，不经过 page cache 中转。另外，GoFS 支持同步和异步 I/O，采用轮询方式处理 I/O 完成。
数据一致性：针对 GPU 和 CPU 共享使用文件系统带来一致性问题，采用主从模式，主机 CPU client 访问文件系统需要得到 GPU 守护线程的授权。GoFS 沿用 F2FS 的检查点机制保障崩溃一致性。
数据安全性：GoFS 利用 GPU 的虚拟内存机制来实现内存隔离，守护进程的内存空间类似于内核空间。针对文件访问权限控制，GoFS 依赖可信任的主机 CPU Client 来为每个用户进程分配一个独特的 ID 和指纹，传递给 GPU 守护进程，后者维护进程 ID 与指纹之间的映射表。当用户进程调用 GoFS API 时会将其指纹也发送给守护进程，用作权限认证。
(4) 实验评估
实验平台与配置：服务器配置 16-core Intel Xeon W5-3435 CPU 和一个 NVIDIA A100 显卡（显存为 40GB），文件系统运行于 2TB SSD 上。
对比方案与测试负载：
对比方案包括： ① Basic 方案采用传统的 CPU I/O 路径，先将文件数据读到 CPU 内存，然后拷贝到 GPU 显存；② GPUfs 方案允许 GPU 线程调用文件操作 API 远程访问主机 CPU 端文件系统；③ cuFile 方案采用 GPUDirect Storage 技术，绕过 CPU 内存将数据直接传输到 GPU 显存；③ GeminiFS (FAST'25) 方案（已在本文第3章介绍）。
测试负载包括：微基准测试（随机/顺序文件读写）和多个真实应用（智能查询 IIR/TIR/MIR、大模型 RAG、图计算 BFS/CC、GNN 训练、图片预处理）。
主要测试结论：
微基准测试：GoFS 的性能随着 GPU 并行度（线程块数量）、SSD 数量的增加而线性增长，明显优于对比方案，而对 CPU 核心数不敏感。GoFS 在顺序读写上可达到接近设备上限的带宽；在随机访问与多文件场景中优势更明显，显著降低小 I/O 和多文件元数据处理开销。
真实应用测试：将各个应用的执行时间大幅缩短，吞吐量大幅提升，可达一个数量级以上。
4. 论文评述
在 AI 时代 GPU 的重要性日益凸显，为 GPU 设计文件系统和构建独立的存储栈，能够使 GPU 应用以标准的文件接口直接访问存储设备，避免 CPU 软件栈、以及 CPU 与 GPU之间同步引起的性能开销。无疑，这是一个非常有趣和有意义的研究方向。笔者不是 GPU 和文件系统方面的专家，在此针对 GPU 文件系统技术和以上两篇论文做一些粗浅探讨。
(1) GPU 原生文件系统是否可行
首先值得思考的问题是——为 GPU 设计实现一个原生的通用的文件系统是否可行。从计算架构与负载特征之间的匹配度看，GPU 采用 SIMT（单指令多数据流）架构，为大规模并行计算而生，擅长处理数据密集型、计算和控制逻辑简单、分支预测少的任务（如矩阵运算和图形渲染）。
相对地，文件系统操作充满了复杂的、串行的、状态依赖的控制流。例如，打开文件包含逐级解析路径名、访问目录项和 inode、检查权限、分配文件描述符等操作；写文件涉及访问页缓存、分配块地址、更新元数据、写日志、写数据、写元数据等操作；在操作过程中充满分支、循环和锁。另外，文件系统需要维护多种元数据，相关操作是小规模、延迟敏感、需严格一致性保障的，这与 GPU 的高并行架构和高吞吐特征不匹配。
除此之外，GeminiFS 和 GoFS 论文中识别出了诸多挑战：如何解决元数据同步问题以使 CPU 与 GPU 能够共享使用文件系统、GPU 全局页缓存、数据一致性和安全性等。这些问题在论文中只得到了部分解决，且其方案引入了严格的假设限制。例如，GeminiFS 限制了存储负载特征；GoFS 依赖主机 CPU 端用户态 client 程序是可信任的来帮助保障安全性，而且对用于保障崩溃一致性的检查点机制没有做充分讨论。
综上所述，在 GPU 上运行文件系统会存在计算并行度低、线程束发散等问题，可能导致 GPU 的计算优势将荡然无存，而且存在严峻的数据一致性和安全性挑战。因此，笔者对基于当前架构构建 GPU 原生文件系统的可行性存疑。
(2) 两篇论文：脚踏实地 vs. 仰望星空
作为 GPU 文件系统方向上的最前沿探索，两篇论文给出了截然不同的路线选择。GeminiFS (FAST'25) 为 GPU 设计了一个由 CPU 主管的伴生型文件系统，支持 page cache，而 GoFS (SOSP'25) 绕过 CPU 构建了一个由 GPU 主管的文件系统，摒弃了 page cache。
笔者认为， 尽管对 GPU 应用的存储负载特征具有较强的假设限制，但是 GeminiFS “脚踏实地”做出了一个务实选择，为 GPU 文件系统开辟出一条可行的道路。相比而言，GoFS 给我们提供了一个“仰望星空”的美丽想象，但其现实价值有待实际检验。
GeminiFS 的务实之处（也是可贵之处）在于，认为为 GPU 实现一个原生的文件系统在当前不是一个现实的选择，在此前提下选择了一条“做减法”的设计思路。文件系统主要运行在 CPU 端，GPU 侧只维护必要的最少的元数据，做尽可能简单的文件系统逻辑处理，在 CPU 与 GPU 之间以文件内嵌的方式同步元数据。这是一个实用且聪明的做法。
GoFS 非常勇敢地尝试构建 GPU 原生文件系统，在支持高并发元数据访问、保障数据一致性和安全性方面做出了不少努力。作为第一个突破 GPU 原生文件系统的研究工作，它需要提供扎实深入的分析解决前面提到的质疑。然而，这项研究工作至少在如下方面存在缺失，总体上无法说服笔者构建 GPU 原生文件系统是可行的。
第一，尽管实验做了多个系统级宏观场景评估，但是没有微观分析在 GPU 上执行文件系统不同操作的效率，并与 CPU 端的执行效率做对比。考虑到 GPU 计算架构与文件系统负载特征不匹配，做这种分析十分有必要。
第二，GoFS 采用的是日志结构文件系统，基于 F2FS 改造而来。该类文件系统有两个关键机制——垃圾回收和检查点，它们对系统的性能和一致性具有重要影响。但是，论文没有对它们的实现和开销展开充分讨论和实验评估。例如，一个值得注意的点是：原版 F2FS 最多只支持打开 6 个 segments 同时写入，而 GoFS 大幅提高了并发写 segments 的数量，这会导致数据布局碎片化和垃圾回收开销增大，以及检查点操作需要持久化的元数据增多。
另外，还有一些地方值得做进一步说明。例如，如果支持 CPU 与 GPU 同时访问 GoFS 中的不同文件，如何解决共享元数据的修改和同步问题；如果 CPU 端用户态 client 程序不可信任，如何保障安全性。GeminiFS 已经开源，而笔者没有找到 GoFS 的开源链接。
总之，GeminiFS (FAST'25) 和 GoFS (SOSP'25) 两篇论文在 GPU 文件系统方向上都做出了非常有启发性的探索。在当前的 GPU 架构下，难以实现落地原生的通用文件系统。未来，GPU 架构的演进是否支持高效运行通用的文件系统，是否会出现一个面向 GPU 的简单化专用化的文件系统，让我们拭目以待。