从零开发分布式文件系统（5.2) IO模型的选择

从零开发分布式文件系统（5.1）:告别传统I/O栈，开启用户态驱动与异步并发的NVMe时代

一、大纲

英文原文:

❝

To answer these questions, we first perform an experimental study of the hardware characteristics of NVMe flash storage in Section 2. Based on the findings, we derive implications for high-performance storage engines. Section 3 then presents a blueprint for an I/O backend that can fully exploit NVMe arrays.

中文翻译:

❝为了回答这些问题，我们首先在第2节中对NVMe闪存存储的硬件特性进行了一项实验研究。 啥意思：裸盘性能，与软件无关？

❝

基于这些发现，我们推导出其对高性能存储引擎的启示。 啥意思：设计一个存储引擎 从那个角度考虑？ 随后，第3节提出了一个能够充分利用NVMe阵列的I/O后端蓝图。 啥意思：如何充分利用NVMe？

🔍 重点IT词汇解析

论文中新的存储引擎 （LeanStore）实现的效果

英文原文

Results.We evaluate our design in Section 4.

实验结果。我们在第4节中对设计进行了评估

On a server with 64 cores and 8 SSDs, the resulting system indeed achieves 12.5 M lookups per second for the random lookup workload. 一台配备64核CPU和8个SSD的服务器上，最终系统在随机查找工作负载中每秒可完成1250万次查找

❝画外音：突破千万,M 代表兆（Mega），即一百万（10^6）

On the much more challenging TPC-C benchmark with a 400 GB buffer pool and a 4 TB dataset, LeanStore executes over 1 M TPC-C transactions per second.

在更具挑战性的TPC-C基准测试中（设置400 GB缓冲池和4 TB数据集）， LeanStore每秒可执行超过100万笔TPC-C交易。

二、章节：Section 2 对裸盘 NVMe flash storage做了什么测试

线性增长

线性增长

吞吐量确实与

固态硬盘数量呈完美线性增长

使用8个驱动器，我们应能达到惊人的1200万IOPS。

注意：软件不具备这样的能力

为什么选择page size 4K 最佳

较大页面的主要缺点在于内存外工作负载上的I/O放大。 However, the big downside of larger pages is I/O amplification on out-of-memory workloads.

例如，使用16 KB页面，读取或写入100字节的记录会导致160倍的I/O放大。

With 16 KB pages, for example, reading or writing 100 Byte records results in an I/O amplification of 160x.

I/O放大（I/O Amplification）

• 定义：实际物理I/O数据量远大于所需逻辑数据量的现象
• 比喻：就像你想从图书馆借一本100页的书中的某一页，但图书馆规定必须借整本书（比如1600页）

我们认为，较低的延迟和I/O放大带来的收益， 使得4 KB页面成为为内存外性能优化的系统的最佳选择。

We argue that the gains from lower latency and I/O amplification make 4 KB pages the best choice for systems that optimize for out-of-memory performance.

作为英语学者，我将为您剖析这个句子中的重点词汇，并解释它们在学术论证语境下的精确含义和作用。

三、选择什么I/O Interfaces

接口的本质： 无论用哪个库，最终目标都一样：把I/O请求塞进NVMe的提交队列，然后等SSD处理完，再从完成队列里取结果。

区别在于“塞”和“取”的方式。

Blocking POSIX interface.

libaio: traditional asynchronous interface

io_uring: modern asynchronous interface.

1. 阻塞式POSIX接口（read/write）

• 怎么用： 最传统的方式。线程发一个请求，然后就被内核“挂起”（阻塞），直到SSD干完活才被唤醒。
• 架构师视角：简单，但性能差。
• 一个线程一次只能处理一个I/O，要榨干SSD的性能，
• 你得启动成千上万个线程，上下文切换开销巨大，完全不现实。这是给慢速磁盘时代设计的模式。

2. 传统异步接口（libaio）

• 怎么用： 进步了。可以一次性提交一批请求（io_submit），然后立刻返回，不阻塞。程序需要自己轮询（get_events）来检查哪些请求完成了。
• 架构师视角：减少了系统调用次数，一个线程能管理多个并发I/O。
• 但接口比较原始，而且在高并发下，轮询和事件获取的效率可能成为瓶颈。

3. 现代异步接口（io_uring）

• 怎么用： Linux内核的“新宠”。它在用户态和内核态之间建立了共享的环形队列。用户程序把请求丢到提交队列，发个信号（io_uring_enter）通知内核去处理。内核处理完，把结果放到完成队列。
• 高级模式（SQPOLL）： 内核可以开个专门的线程来轮询提交队列，这样连发信号这个系统调用都省了，进一步降低延迟。
• 高级模式（IOPOLL）： 可以关掉硬件中断，让应用自己轮询完成队列。在超高IOPS场景下，这能减少中断开销，提升性能。
• 架构师视角：目前Linux上最先进、最灵活的通用异步I/O方案。 它试图在易用性和极致性能之间找到平衡，支持多种优化模式。

4. 用户态I/O（SPDK）

• 怎么用： “掀桌子”的方案。完全绕过操作系统内核（文件系统、块设备层、页缓存）。直接在用户态分配和管理NVMe的队列对。提交请求就是往内存里的环形缓冲区写条记录，然后通知一下SSD

io_uring 是如何工作的？

io_uring 的核心创新在于使用了共享内存环形队列，极大地减少了用户程序与内核之间的通信开销。

它的架构如图 5c 所示，主要包含两个队列：

1. 提交队列（Submission Queue, SQ）：位于用户程序和内核共享的内存中。当程序要发起 I/O（如读、写）时，它不再调用系统调用，而是直接把请求描述符写入这个队列。
2. 完成队列（Completion Queue, CQ）：同样位于共享内存中。当内核（或SSD）处理完一个 I/O 请求后，会把完成的结果（成功/失败、字节数等）写回这个队列

四、NVMe Queue Pair 是什么

NVMe Queue Pair是硬件层面的高性能生产-消费者模型

简单来说，一个NVMe Queue Pair（队列对）就是主机（CPU）与NVMe固态硬盘（SSD）之间进行通信的一对“指令通道”。

一个Queue Pair由两个独立的队列组成，其分工与协作关系如下：

💡 为什么Queue Pair设计如此重要？

这种分离的队列对设计带来了几个关键优势，正是NVMe性能远超旧协议（如AHCI）的原因：

• 极高的并行性：一个NVMe设备可以支持多个（如64K个）Queue Pair。每个CPU核心可以拥有自己专属的Queue Pair，从而彻底避免了多核争用同一队列的锁开销，实现了真正的并行I/O。
• 极低的软件开销：命令提交和完成通知通过简单的内存写入和门铃寄存器操作完成，流程极其精简，远少于旧协议所需的复杂寄存器操作。
• 深度队列支持：单个SQ的深度（可容纳的命令数）很大（如64K），允许主机一次性提交大量I/O请求，让SSD能够充分发挥其内部并行处理能力，优化调度。
• 与现代I/O模型天然契合：你可以将io_uring的SQ/CQ看作是在软件层对NVMe硬件SQ/CQ架构的模仿和延伸。io_uring在应用与内核之间建立了一对高效的异步队列，而NVMe QP在内核与硬件之间建立了另一对。两者结合，构成了一条从应用到硬件的、完整的、无阻塞的异步I/O流水线。

两种具体的Poll模式详解