【存储工程】O_DIRECT 与 io_uring：固定缓冲区、register_buffers 与工程选型

数据库和块存储引擎常同时遇到两件事：用 O_DIRECT 绕过 Page Cache 避免双重缓冲（见 #10 Direct I/O），以及 用 io_uring 降低 syscall 开销（见 io_uring 内核内部）。两者可以组合，但对齐、posix_memalign、io_uring_register_buffers 和 IOSQE_FIXED_FILE 各有一层约束。本文把组合路径、实测数据和选型边界写清楚。

测试环境说明 下文 benchmark 在 Linux 6.6.87（WSL2）、liburing 2.14、ext4 文件系统、/tmp 上实测。块设备裸盘与 NVMe 上的绝对 IOPS 会更高；结论侧重路径差异与约束，不跨环境比绝对数值。

一、为什么要把两者放在一起

flowchart LR
    APP[应用 Buffer Pool]
    UR[io_uring SQ/CQ]
    VFS[VFS + 文件系统]
    PC[Page Cache]
    DISK[块设备]
    APP -->|O_DIRECT 路径| UR --> VFS --> DISK
    APP -->|缓冲 I/O| UR --> VFS --> PC --> DISK

O_DIRECT 解决缓存语义；io_uring 解决提交效率。互不替代。

二、O_DIRECT 硬约束（复习）

来自 #10，组合 io_uring 前必须满足：

1. 缓冲区地址、长度、文件偏移 均按逻辑块大小对齐（ext4 常见 4 KB）。
2. 使用 posix_memalign(4096, size) 或 mmap 对齐映射，不要用普通 malloc。
3. 文件系统与块层需支持 direct I/O；部分网络文件系统不支持或行为怪异。
4. O_DIRECT 与 mmap 同一文件混用会踩坑；sendfile 等页缓存路径与 direct fd 不兼容。

void *buf;
posix_memalign(&buf, 4096, 4096);
int fd = open(path, O_RDWR | O_CREAT | O_TRUNC | O_DIRECT, 0644);

三、io_uring 固定缓冲区：io_uring_register_buffers

3.1 作用

每次 read/write 传统路径需要 pin 用户页。io_uring_register_buffers() 预先注册一组 iovec，内核长期持有映射，后续 SQE 可通过 buf_index 引用，减少 per-I/O 页表开销。

struct io_uring ring;
io_uring_queue_init(256, &ring, 0);

struct iovec iov = { .iov_base = aligned_buf, .iov_len = 4096 };
io_uring_register_buffers(&ring, &iov, 1);

struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);
io_uring_prep_write(sqe, fd, NULL, 4096, offset);
sqe->buf_index = 0;   /* 使用注册缓冲区槽位 0 */
io_uring_submit(&ring);

与 IORING_REGISTER_FILES（固定 fd 槽位）独立：前者优化缓冲区 pin，后者优化 fd 查找。

3.2 与 O_DIRECT 叠加时的注意点

• 注册缓冲区本身必须是 O_DIRECT 合法的对齐内存。
• 部分内核版本对 register_buffers + O_DIRECT + NULL 用户地址组合的行为曾有 bug；升级内核后应回归测试。
• 本文环境实测：O_DIRECT + 普通 io_uring_prep_write(sqe, fd, buf, ...) 成功；register_buffers + buf_index 路径返回 -EFAULT（14）——说明该组合在当前 WSL2 6.6 栈上未走通，生产启用前必须在目标内核上验证。

3.3 Provided Buffers（进阶）

IOSQE_BUFFER_SELECT + io_uring_setup_buf_ring 是更新的缓冲池模型（见 io_uring 高级特性），适合网络收包；块设备 Direct I/O 场景更常见仍是 register_buffers 或每请求显式缓冲区。

四、实测：三种 io_uring 写路径（10k × 4KB）

测试程序对同一 ext4 文件顺序写 10000 次 4 KB（约 40 MB），对比：

1. 缓冲 I/O + io_uring（无 O_DIRECT）
2. O_DIRECT + io_uring（对齐缓冲，无 register）
3. O_DIRECT + register_buffers（本文环境失败）

buffered io_uring write:     0.284 s, ~35242 IOPS
O_DIRECT io_uring write:     0.271 s, ~36840 IOPS
O_DIRECT + register_buffers: EFAULT（未成功完成）

解读（限于本环境）：

• 40 MB 规模下，缓冲与 Direct 的 IOPS 接近——瓶颈尚未到设备上限，差异主要体现在是否污染 Page Cache。
• register_buffers 失败说明：不能假设注册缓冲在所有 Direct 组合下开箱即用，需单独测通再上线。

完整复现可参考 liburing 示例 examples/reg-wr 与 man io_uring_register_buffers。

五、与 epoll / 同步 read 的选型

io_uring 不是 epoll 的完全替代；O_DIRECT 也不是所有存储栈的默认。组合用于：已决定绕过页缓存，且需要批量异步提交。

六、工程检查清单

□ 缓冲区 4K（或设备块大小）对齐
□ open 带 O_DIRECT；ftruncate 预分配避免 ENOSPC 中途失败
□ 文件系统 block size 与 I/O 大小兼容
□ io_uring register_buffers 在目标内核实测通过
□ 监控 iowait 与 Buffer Pool 命中率，确认没有「双缓存」
□ 与 fsync/fsync 策略一致（见 #12 数据完整性）

七、与系列文章的衔接

• 页缓存路径：Page Cache、Linux I/O 栈
• io_uring 机制：内核内部、异步 I/O 综述
• liburing API：io_uring 系列、Golang 集成

参考资料

• Linux man 2 open（O_DIRECT）、man io_uring_register_buffers
• Linux 内核：fs/direct-io.c、io_uring/opdef.c
• J. Axboe, io_uring 设计文档 —— https://kernel.dk/io_uring.pdf
• 本站 #10 Direct I/O、#64 存储基准测试

复现 benchmark：examples/storage/79-o-direct-io-uring/（make && make run）

上一篇: 存储事故复盘 相关: io_uring 内核内部 · Direct I/O 详解 · Linux 异步 I/O