1. 论文基本信息 (Bibliographic Information)

• 标题 (Title): GeminiFS: A Companion File System for GPUs (GeminiFS: 一个为 GPU 设计的伴生文件系统)
• 作者 (Authors): Shi Qiu, Weinan Liu, Yifan Hu, Jianqin Yan, and Zhirong Shen (厦门大学 NICE 实验室); Xin Yao, Renhai Chen, and Gong Zhang (华为理论实验室); Yiming Zhang (厦门大学 NICE 实验室 和 上海交通大学)
• 发表期刊/会议 (Journal/Conference): 23rd USENIX Conference on File and Storage Technologies (FAST '25)。FAST 是文件和存储技术领域的顶级学术会议，享有极高的声誉和影响力。
• 发表年份 (Publication Year): 2025
• 摘要 (Abstract): 论文摘要指出，现有的以 GPU 为中心的存储方案虽然通过绕过 CPU 实现了 GPU 对 NVMe 存储的直接访问，但缺乏传统文件系统的文件抽象和管理功能（如隔离和访问控制），无法满足 GNN、LLM 等机器学习应用对快速文件访问和数据共享的需求。为此，论文提出了一个名为 GeminiFS 的伴生文件系统。GeminiFS 为 GPU 程序提供了文件系统接口，使其能够直接以文件为单位访问由主机文件系统管理的 NVMe 存储。它通过将元数据嵌入文件内部实现主机与 GPU 文件系统间的元数据同步，扩展了 NVMe 驱动以支持 CPU 和 GPU 并行建立控制平面，并设计了 GPU 友好的页缓存。实验证明，GeminiFS 在大规模机器学习负载下显著优于现有方案。
• 原文链接 (Source Link): /files/papers/68e0aa4e89df04cda4fa2827/paper.pdf (论文已发表于 FAST '25 会议论文集)

2. 整体概括 (Executive Summary)

• 研究背景与动机 (Background & Motivation - Why):

  • 核心问题: 现代机器学习（ML）应用，如大语言模型（LLM）和图神经网络（GNN），其数据集和模型权重的大小已远超单块 GPU 的显存容量。
  • 现有挑战:
    1. CPU 中心 (CPU-centric) 的存储方案： 如 GPUfs 和 GDS，依赖 CPU 来发起存储访问，导致了高昂的 CPU-GPU 同步开销、I/O 流量放大和 CPU 处理延迟，成为性能瓶颈。
    2. GPU 中心 (GPU-centric) 的存储方案： 如 BaM，允许 GPU 直接向 NVMe 设备发送 I/O 命令，性能很高，但它将存储视为原始块设备，缺乏文件系统的抽象和管理功能。这使得数据共享、访问控制、数据一致性和完整性保证变得非常困难，不便于实际的 ML 场景应用。
  • 切入点: 现有方案要么慢但方便（CPU-centric），要么快但不方便（GPU-centric）。本文的创新思路是设计一个既能实现 GPU 直接访问存储的高性能，又具备文件系统易用性和管理功能的方案。GeminiFS 作为一个“伴生”文件系统，它不试图在 GPU 上重建一个完整的、独立的操作系统，而是与主机文件系统协同工作，巧妙地解决了这一矛盾。

• 核心贡献/主要发现 (Main Contribution/Findings - what):

  • 提出 GeminiFS 伴生文件系统架构: 这是首个以 GPU 为中心、同时提供文件系统接口的存储方案，让 GPU 程序能直接、按需地以文件为单位访问磁盘数据，而无需 CPU 介入。
  • 设计了 GVDK 文件格式: 通过将必要的文件元数据（如逻辑块到物理块的映射）直接嵌入文件自身，实现了主机和 GPU 之间高效、轻量级的元数据同步。
  • 扩展了 NVMe 驱动 (SNVMe): 提出了一个共享的 NVMe 驱动，允许 CPU 和 GPU 并行地为同一存储设备建立各自的控制平面（I/O 队列），这是实现 GPU 直接提交 NVMe 文件请求的关键基础设施。
  • 设计了 GPU 友好的页缓存 (Page Cache): 在 GPU 端实现了一个软件定义的页缓存，能够充分利用 GPU 内部的高带宽（HBM），并通过跨进程共享和低锁竞争设计来优化性能。
  • 提供了 libGemini 编程库: 封装了底层的复杂性，为 GPU 开发者提供了简洁的 POSIX-like API，降低了编程难度。

3. 预备知识与相关工作 (Prerequisite Knowledge & Related Work)

• 基础概念 (Foundational Concepts):

  • CPU 中心 (CPU-centric) vs. GPU 中心 (GPU-centric) 存储访问: 这是理解本文工作的基础。如下图所示，CPU-centric 架构中，所有存储请求都由 CPU 发起和管理，数据可能需要经过 CPU 内存中转。而 GPU-centric 架构中，GPU 可以直接向 NVMe 设备发送 I/O 命令，完全绕过 CPU，数据直接在 GPU 显存和 NVMe 存储之间传输。

    

  • NVMe (Non-Volatile Memory Express): 一种专为固态硬盘（SSD）设计的高速存储接口协议。它通过在内存中建立提交队列 (Submission Queues, SQ) 和完成队列 (Completion Queues, CQ) 来实现主机与设备间的高效通信。GPU-centric 方案的核心就是将这些队列置于 GPU 显存中。

  • 文件系统元数据 (File System Metadata): 用于描述和管理文件的数据，例如文件名、大小、权限、创建时间，以及最重要的——文件逻辑块地址到磁盘物理块地址的映射关系（如 inode 和 extent tree）。在 GPU 上维护这些复杂、状态化的元数据是极其困难的。

• 前人工作 (Previous Works):

  • CPU-centric 方案:
    • GPUfs: 允许 GPU 程序通过类似系统调用的方式请求 CPU 访问文件。但 CPU 的低并行性无法满足 GPU 成千上万线程的需求，导致严重性能瓶颈。
    • GDS (GPUDirect Storage): NVIDIA 官方方案，建立了 GPU 显存和存储之间的直接数据通路（DMA），但控制流仍需 CPU 发起。其批处理接口 cuFileBatchIOSubmit 的并发能力有限（最多 128 个操作），无法满足 GPU 的高并发需求。
  • GPU-centric 方案:
    • BaM (Big accelerator Memory): 实现了将 NVMe 队列置于 GPU 显存中，让 GPU 线程可以直接提交 I/O 命令。性能极高，但它将 NVMe 设备作为一个裸盘（raw device）来用，没有任何文件系统概念，导致数据无法在不同 GPU 进程或 CPU/GPU 进程间方便地共享和管理。

• 技术演进 (Technological Evolution): 技术演进的脉络是：CPU 代理 I/O (GPUfs) -> CPU 控制、GPU 直接数据传输 (GDS) -> GPU 直接控制和数据传输但无文件系统 (BaM) -> GPU 直接控制和数据传输且有文件系统 (GeminiFS)。GeminiFS 正是站在 BaM 的肩膀上，解决了其最大的短板——文件系统缺失的问题。

• 差异化分析 (Differentiation): 与 BaM 相比，GeminiFS 的核心创新在于增加了文件系统抽象，通过与主机文件系统协同的方式，而不是抛弃它。与 GDS 和 GPUfs 相比，GeminiFS 的核心优势在于彻底绕过了 CPU 控制路径，实现了真正的 GPU-centric I/O，从而获得了极大的性能提升。

4. 方法论 (Methodology - Core Technology & Implementation Details)

GeminiFS 的架构如下图所示，其核心设计思想是“伴生”：让主机文件系统负责复杂的文件管理（创建、删除、目录等），而 GeminiFS 在 GPU 端专注于提供高性能的文件数据读写。

• 方法原理 (Methodology Principles):

  • 通过元数据嵌入实现 CPU-GPU 同步 (CPU-Bypassing via Metadata Embedding):

    • 核心思想: 不在 GPU 上实现复杂的元数据管理逻辑（如日志、事务），而是将一个文件所需的私有元数据（Private Metadata）直接嵌入到文件开头的块中。这样，当 GPU 需要访问文件时，只需读取文件的第一个块，就能获得所有必要的地址映射信息，从而独立完成 I/O 操作。

    • GVDK (GPU virtual disk format) 文件格式: 这是实现元数据嵌入的具体方案。如下图所示，一个 GVDK 文件的头部包含了文件类型、大小、访问模式等信息，最关键的是一个两级映射表 (L1 & L2 Tables)。这个映射表直接存储了文件逻辑块到 NVMe 物理地址的映射关系。

    • **GVDK Helper: 一个运行在主机内核的模块，它在创建 GVDK 文件时，会从主机文件系统（如 EXT4）获取物理块地址，并将其预先填充到文件的映射表中。这相当于把地址翻译工作从 GPU 运行时（runtime）提前到了文件创建时，极大地简化了 GPU 端的逻辑。

      

  • CPU/GPU 共享 NVMe 驱动 (CPU/GPU Shared NVMe Driver - SNVMe):

    • 核心思想: 修改现有的内核 NVMe 驱动，使其能够同时管理和注册来自 CPU 内存和 GPU 显存的 I/O 队列。
    • 实现步骤:
      1. 在 GPU 显存中分配 I/O 队列所需的内存。
      2. 通过 GPU 驱动提供的 nvidia_p2p_* API，将这块显存“钉住” (pin) 并获取其对应的 DMA 地址，使 NVMe 设备可以直接访问。
      3. 在 NVMe 设备初始化时，SNVMe 驱动不仅会注册主机端的 I/O 队列，还会将这些位于 GPU 显存中的队列一并注册到 NVMe 控制器。这样，CPU 和 GPU 就拥有了各自独立的、通往同一 NVMe 设备的命令通道。

  • GPU 专用的页缓存 (GPU-Specific Page Cache):

    • 核心思想: 在 GPU 显存中构建一个页缓存，以利用其远超 PCIe 带宽的内部 HBM 带宽（高达~2TB/s），从而加速重复数据访问。
    • 关键设计:
      1. 跨进程共享: 由于页缓存位于 GPU 用户进程空间，为避免每个进程都创建一份缓存造成浪费，GeminiFS 在主机 SNVMe 驱动中设计了一个管理模块。当一个进程创建页缓存时，它会获取一个进程间通信句柄（IPC handle），其他进程可以通过此句柄映射到同一块缓存显存。
      2. 低锁竞争: GPU 的高并行性会加剧锁竞争。GeminiFS 采用两种策略缓解：
         • warp 级页面获取: 一个 warp (通常是 32 个线程)作为一个单元来请求页面，而不是每个线程单独请求，将并发竞争者数量从数千降低到数百。
         • 常数时间容器: 使用哈希表和双向链表的组合来管理缓存页面，使得插入、删除和查找操作的时间复杂度都是 O(1)，最大限度地缩短了临界区（critical section）的锁定时间。

• 方法步骤与流程 (Steps & Procedures): 下图详细展示了使用 GeminiFS 进行文件操作的完整生命周期：

  

  1. 系统启动 (System Startup): 调用 Geminifs_init，在指定的 GPU 上创建 NVMe I/O 队列，并初始化 SNVMe 共享驱动。
  2. 文件创建/预分配 (GVDK File Pre-allocation):** 在主机端调用 G_open 并带 O_CREAT 标志。主机文件系统创建文件，GVDK Helper 模块获取物理块信息并将其嵌入文件头部的元数据区。
  3. 文件打开 (GVDK File Open): GPU 应用调用 G_open。GeminiFS 读取文件的第一个块，将其中的元数据（包括地址映射表）缓存到 GPU 显存中。
  4. 文件读写 (GVDK File Read/Write): 在 GPU 核函数 (kernel) 中调用 G_read/G_write。libGemini 利用缓存的映射表将文件偏移量转换为 NVMe 物理地址，构建 NVMe 命令，并直接提交到 GPU 上的 I/O 队列。
  5. 文件关闭 (GVDK File Close): 调用 G_close，释放 GPU 上的元数据缓存和页缓存。如有必要，通过 G_sync 将脏数据和元数据同步回磁盘。

5. 实验设置 (Experimental Setup)

• 数据集 (Datasets): 实验主要分为微基准测试 (microbenchmark) 和真实应用测试。
  • 微基准测试: 主要使用大文件进行 4KB 粒度的随机/顺序读写，以测试系统的原始 I/O 性能。
  • 真实应用: 使用 GPT2-124M 大语言模型进行训练，这是一个包含 1.5 亿参数的模型，能够真实反映 LLM 训练中的存储访问模式。
• 评估指标 (Evaluation Metrics):
  • 带宽 (Bandwidth): 单位为 MB/s 或 GB/s，衡量数据传输的速率，越高越好。
  • 延迟 (Latency): 单位为微秒 (μs)，衡量单个 I/O 操作完成的时间，越低越好。
  • 系统运行时间 (System Runtime): 单位为秒 (s)，衡量完成整个应用（如 LLM 训练）的总时间，越短越好。
• 对比基线 (Baselines):
  • GPUfs: 代表性的 CPU-centric 方案，通过 CPU 代理 I/O。
  • GDS (NVIDIA GPUDirect Storage): 业界主流的 CPU-centric 方案，CPU 控制，GPU 直接数据传输。
  • BaM: 代表性的 GPU-centric 方案，直接访问裸盘，无文件系统。
  • Native: 使用标准的文件 I/O (read/write) + cudaMemcpy 的传统方式。
  • DLRover-RM: 一个针对深度推荐模型训练优化的系统，提供快速的异步检查点机制。

6. 实验结果与分析 (Results & Analysis)

• 核心结果分析 (Core Results Analysis):

  • 微基准性能对比:

    • 带宽: 如下图所示，在 4KB 读操作中，随着并发线程数的增加，GeminiFS 的带宽表现与 BaM 非常接近，并且能够跑满 NVMe 设备的物理带宽（约 6000 MB/s）。相比之下，GPUfs 和 GDS 由于 CPU 瓶颈，带宽很早就饱和在较低水平。这证明了 GeminiFS 在架构上的优越性。GeminiFS 比 BaM 略低的性能是文件系统元数据解析带来的开销，但这个代价换来了文件管理的便利性。

      

    • 延迟: 延迟测试结果（详见原文 Figure 7）同样显示，GeminiFS 的延迟远低于 GPUfs 和 GDS（在高并发下），且与 BaM 相差无几，再次验证了绕过 CPU 带来的巨大好处。

• 页缓存性能分析 (Page Cache Analysis):

  • Warp 数量的影响: 如下图所示，页缓存的读写带宽随着 warp 数量的增加而线性增长，在 1024 个 warp 时达到惊人的 650 GB/s。这表明 GeminiFS 的低锁竞争设计非常成功，并且页缓存的性能远超当前 NVMe 设备的带宽，绝不会成为瓶颈。

    

  • 页面大小的影响: 如下图所示，使用更大的页面（Page Size）可以获得更高的带宽，因为单次操作传输的数据更多，分摊了开销。当页面大小达到 1024KB 时，带宽接近了 GPU 内部内存拷贝的理论极限。

    

• 真实应用性能 (LLM 训练):

  • 场景一：不卸载激活值 (Disable_Offloading): 如下图 (a) 所示，此时 I/O 主要发生在模型权重加载和检查点（Checkpoint）写入。GeminiFS 相比 Native、DLRover-RM 和 GDS 分别将总训练时间减少了 25%、12% 和 10%。这主要得益于其极快的检查点写入速度。

  • 场景二：卸载激活值 (Enable_Offloading): 如下图 (b) 所示，当 GPU 显存不足，需要将中间计算结果（激活值）频繁换入换出到存储时，GeminiFS 的优势被急剧放大。它将训练时间相比 Native 和 GDS 分别减少了 94.5% 和 91%。这是因为激活值卸载产生了大量小 I/O，CPU-centric 方案在这种场景下因频繁的 CPU-GPU 通信而彻底崩溃，而 GeminiFS 则能高效处理。

    

7. 总结与思考 (Conclusion & Personal Thoughts)

• 结论总结 (Conclusion Summary): 论文成功地设计并实现了一个名为 GeminiFS 的伴生文件系统。它创新性地结合了 GPU-centric 架构的高性能和传统文件系统的易用性。通过将元数据嵌入文件、共享 NVMe 驱动和设计 GPU 友好的页缓存等关键技术，GeminiFS 为需要大规模数据访问的 GPU 应用（特别是 LLM 和 GNN）提供了一个前所未有的高效、便捷的存储解决方案。

• 局限性与未来工作 (Limitations & Future Work):

  • 局限性:
    1. 当前设计主要针对 ML 负载中常见的只读或仅追加（append-only）的访问模式。对于需要频繁随机写入和元数据更新的通用工作负载，性能可能受影响。
    2. GVDK 文件格式会引入少量存储开销（文中提到约 0.2%）。
    3. 对不可预测的 I/O 模式支持有限。
  • 未来工作:
    1. 支持多 GPU: 扩展 GeminiFS 以支持多 GPU 并行读写文件。
    2. 聚合多 NVMe 设备: 使用 RAID 等技术聚合多个 NVMe 设备的带宽，以满足多 GPU 的需求。
    3. 支持不可预测工作负载: 采用文件预分配等策略来应对。
    4. 框架集成: 将 GeminiFS 集成到 PyTorch、vLLM 等主流 ML 框架中，方便用户使用。

• 个人启发与批判 (Personal Insights & Critique):

  • 启发:
    1. “伴生”设计思想的巧妙之处: 这篇论文最精彩的地方在于没有试图在 GPU 上“造轮子”——从零开始实现一个复杂的通用文件系统，而是采取了与主机系统协同工作的“伴生”模式。这是一种非常务实且高效的工程思路，在解决异构计算系统中的软件栈问题时具有普遍的借鉴意义。
    2. 软硬件协同设计的典范: GeminiFS 的成功依赖于对软件（文件格式、API）、内核（驱动程序）和硬件（GPU 架构、NVMe 特性）的深刻理解和协同设计。它充分利用了 GPU 的并行计算能力和 NVMe 的低延迟特性，是一个出色的系统级工作。
  • 批判性思考:

    1. 工作负载的普适性: 论文的论证和实验强依赖于 ML 负载的特性（如访问模式可预测、数据多为只读或追加）。GeminiFS 在更通用的计算场景（如数据库、科学计算）下的表现如何，是一个值得探讨的问题。其元数据嵌入和预翻译机制可能不适用于元数据频繁动态变化的场景。

    2. 安全性和隔离: 尽管论文提到可以通过完整性检查来防止元数据篡改，但让用户态的 GPU 程序直接访问物理块地址，可能会带来新的安全挑战。如何在提供高性能的同时，保证与主机文件系统同等级别的安全性和多租户隔离，是未来需要进一步完善的方向。

       ---