o_direct要求内存地址、文件偏移和io长度均按逻辑块大小（如4kb）对齐，需用posix_memalign分配缓冲区，并配合data=writeback挂载选项或xfs文件系统；c++中应避免stl流封装，推荐裸posix接口或自定义raii wrapper，结合io_uring或多缓冲提升吞吐。
Linux 下用 O_DIRECT 打开文件必须对齐内存和偏移
直接 IO 不走 page cache，但代价是内核强制校验对齐：缓冲区地址、读写长度、文件偏移都必须是 512 字节（或文件系统逻辑块大小）的整数倍。哪怕只差 1 字节，read() 或 write() 就会返回 -1 并把 errno 设为 EINVAL。
常见错误是直接用 new char[buf_size] 分配缓冲区——它不保证地址对齐。正确做法是用 posix_memalign()：
void* buf;
int ret = posix_memalign(&buf, 4096, 64 * 1024); // 4KB 对齐，64KB 缓冲
if (ret != 0) { /* 处理分配失败 */ }
// 记得用 free(buf) 释放
同时确保 lseek() 偏移和每次 read() 长度也是 4096 的倍数。
O_DIRECT 必须配合裸设备或禁用 ext4 的 journal
在普通 ext4 文件系统上启用 O_DIRECT 后，如果文件有数据 journal（默认开启），内核仍可能绕过你的直写意图——journal 机制会先把数据写进日志区，再刷盘，这本质上仍是缓存路径。实际测试中，你可能看到 write() 返回成功，但磁盘灯没亮、iotop 不显示物理 IO。
解决方法有两个：
- 挂载时加
data=writeback或data=ordered（不推荐data=journal） - 更彻底的是用
dd if=/dev/zero of=/dev/sdX bs=4K count=1000000 oflag=direct测试裸设备，确认是否真走硬件通道
注意：O_DIRECT 在 XFS 上行为更稳定，默认不 journal 数据，更适合大文件直写场景。
C++ 中封装 O_DIRECT 读写要避免 RAII 自动关闭干扰
别用 std::fstream 或 std::ofstream 尝试包装 O_DIRECT——它们内部调用的 write()/read() 无法控制缓冲区对齐，且析构时自动 close() 可能打断未完成的异步 IO。
建议保持 POSIX 接口裸用，并手动管理生命周期：
int fd = open("/path/to/file", O_RDWR | O_DIRECT);
if (fd == -1) { /* handle error */ }
<p>// …… 分配对齐内存、设置偏移、调用 read/write</p><p>// 显式 close，不要依赖局部变量析构
close(fd);</p>
若需 RAII，自己写一个轻量 wrapper，只封装 fd 和对齐 buffer 指针，close() 放在明确位置，不隐藏 IO 调用时机。
性能瓶颈常卡在单线程串行 read()/write() 调用
即使开了 O_DIRECT，如果每读 4MB 就等一次 syscall 返回，CPU 利用率低、吞吐上不去。真实大文件场景（如视频转码、数据库导入）必须结合异步 IO 或多缓冲轮转。
可行方案：
- 用
io_uring提交多个O_DIRECT请求并等待完成（Linux 5.1+，性能提升显著） - 双缓冲 + 线程切换：线程 A 发起
read()到 buf1，线程 B 同时处理 buf0 数据，然后交换 - 避免频繁
lseek()：用pread()/pwrite()显式传入 offset，减少内核态 seek 开销
特别注意：O_DIRECT 的单次最大 IO 长度受内核限制（通常 2MB 左右），超长请求会被截断，需自行分片。
真正难的不是打开 O_DIRECT，而是让整个数据流从内存对齐、文件系统配置、IO 调度策略到用户态调度全部对齐——漏掉任一环，你写的都是“伪直写”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
