O_DIRECT返回EINVAL的根本原因是文件偏移、内存地址、读写长度三者未同时满足文件系统I/O块大小对齐要求，内核在open()时即校验并拒绝非法请求。
O_DIRECT 不能直接开箱即用，根本原因不是权限或 flag 写错，而是三重对齐没做齐：文件 offset、内存地址、读写长度，缺一不可。
为什么 open() 加 O_DIRECT 总是返回 EINVAL
错误不是出在 open() 调用本身，而是调用前没校验对齐条件。Linux 内核在 open() 阶段就检查这三项，任一不满足就拒掉，返回 EINVAL。
- 文件系统逻辑块大小才是真实对齐基准，不一定是 512 —— 用
stat -f /path | grep "I/O Block"查准它（常见值有 512、4096、65536） -
new uint8_t[buf_size]分配的内存几乎必然不对齐；malloc()也不保证页对齐，只保证sizeof(void*)对齐 - 即使你传了
O_DIRECT | O_RDWR，若同时带O_APPEND，内核也会静默拒绝（O_APPEND和O_DIRECT互斥）
如何分配和使用对齐缓冲区
缓冲区地址必须按文件系统 I/O 块大小对齐，且长度也得是其整数倍。别碰 aligned_alloc() 在旧 libc 上的兼容性问题，直接用 POSIX 标准接口：
- 用
posix_memalign(&buf, align_size, size)分配 ——align_size至少填 4096（安全兜底），但最好设为stat -f查到的实际块大小 - 读写时，
offset必须是块大小的倍数；count同样必须是倍数；否则read()/write()仍会返回EINVAL - 别用
lseek()+read()组合来“修正”偏移 ——lseek()成功不代表后续read()就能过，内核只认最终发起读写的那个 offset 是否对齐
pread() 比 read() 更适合 Direct IO 场景
因为 read() 依赖并隐式更新文件当前 offset，一旦某次读写未对齐导致失败，该 offset 就卡在非法位置，后续所有 read() 都会崩。而 pread() 显式传入 offset，每次调用都是独立校验，可控性强得多。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 顺序读写时，自己维护一个对齐后的
off_t cur_off，每次调用pread(fd, buf, count, cur_off)，成功后手动加count - 遇到坏扇区或部分读失败（
errno == EIO），可跳过对应块继续读下一块，read()做不到这点 -
write()同理，优先用pwrite()；注意：Direct IO 下pwrite()不支持offset为 -1 的“追加”语义
写完数据为何 fsync() 也不落盘
O_DIRECT 只绕过了内核 page cache，但不绕过设备自身的 write-back 缓存（比如 SATA SSD 或企业级 HDD）。fsync() 只确保请求送达驱动层，不强制设备刷缓存。
- 最稳妥的做法是在部署阶段关掉磁盘 write-cache：
hdparm -W0 /dev/sdX（需 root，且重启后可能恢复） - 运行时可用
ioctl(fd, BLKFLSBUF)清块设备缓存，但仅对块设备文件有效（如/dev/sdb），对普通文件无效 -
O_SYNC能强制落盘，但性能暴跌 —— 每次write()都等设备确认，不适合高吞吐场景
真正容易被忽略的是：RAII 封装时，free() 必须在 close() 之后执行，且不能用 delete[] —— 对齐内存是 posix_memalign() 分配的，只能用 free() 释放。
