POSIX write失败后文件偏移是否不变？LevelDB/RocksDB WAL相关疑问

我在学习LevelDB和RocksDB时，对它们不依赖截断操作保证WAL（预写日志）数据完整性的机制存在困惑。

我观察到的两个核心现象：

• 日志文件始终对齐到8KiB的块边界，推测块与块之间不存在无效数据
• 日志写入器（及底层的WriteableFile）在写入失败时从不截断文件，而是直接尝试继续写入——这似乎依赖一个前提：写入失败后文件偏移量不会改变，下一次写入能定位到正确位置

但根据POSIX规范的描述：

POSIX.1-2017并未规定返回错误后的文件偏移量值，因为存在太多情况。对于诸如[EBADF]之类的编程错误，该概念毫无意义，因为不涉及任何文件。对于立即检测到的错误（如[EAGAIN]），显然指针不应改变。然而，在中断或硬件错误后，更新偏移量会非常有用，这也是许多实现的行为。

我的疑问是：这种POSIX未明确规定的行为，到底是否应该被依赖？实际生产系统中是否已经确保该行为安全可用？

解答 #

LevelDB/RocksDB的设计确实依赖写入失败后文件偏移量的确定性，但并非无依据地依赖POSIX的模糊规范，而是通过多层机制规避了潜在风险：

1. 块对齐设计的兜底作用 #

日志文件强制对齐8KiB块的设计，本质上是做了一层隔离容错：

• 每个块内部包含校验和，读取时会验证完整性
• 即便某次写入失败导致偏移量异常，后续写入的新块会被完整写入到下一个8KiB边界，旧的不完整块会被校验和识别并丢弃
• 块与块之间的边界是明确的，不会出现跨块的无效数据污染

2. 底层文件系统的实际行为一致性 #

虽然POSIX未强制规定，但主流UNIX-like系统（Linux、BSD、macOS）在处理写入错误时的行为是可预测的：

• 对于EAGAIN/EWOULDBLOCK这类立即返回的错误，偏移量完全不改变
• 对于部分写入（比如写入中途被信号中断），偏移量会更新为实际成功写入的字节数——但LevelDB/RocksDB的写入逻辑会检查返回值，若发现部分写入会直接判定为失败，后续会重新尝试写入整个块
• 对于硬件错误导致的写入失败，多数系统会保留已成功写入部分的偏移量，但此时块校验和会检测到不完整，该块会被标记为无效

3. 写入逻辑的防御性设计 #

LevelDB/RocksDB的WriteableFile实现本身做了防御性处理：

• 每次写入前会记录当前偏移量，写入失败后会主动重新定位偏移量（通过lseek）到预期位置，而非依赖系统自动维护的偏移量
• 对于关键的WAL写入，会强制调用fdatasync确保数据落盘，同时验证写入长度与预期一致，避免静默的部分写入

结论 #

这种行为在实际生产环境中是安全可用的：

• 主流操作系统的行为一致性提供了基础保障
• LevelDB/RocksDB自身的块对齐、校验和、偏移量重定位机制，进一步规避了POSIX规范模糊性带来的风险
• 截断操作本身反而会引入额外的IO开销和一致性风险（比如截断过程中发生崩溃），因此这种设计是权衡后的最优解

内容的提问来源于stack exchange，提问作者fuzhe