线上一个承载 32TB 数据的存储节点做滚动重启。DBImpl::Open判定CURRENT文件不存在，在 3 秒内直接触发了全新建库流程：向数据目录写入全新的MANIFEST-000001，存量数十 TB 的数据块索引指针瞬间被切断。配置清单上白纸黑字写着数据目录早已初始化，但存储引擎却认定这里是一片荒地。
当时整个排查现场所有人都把焦点放在 LSM 压缩回放上，直到翻到底层存储适配层的错误码映射代码才找到元凶。自研的分布式文件系统客户端在网络抖动、元数据租约失效时，把远端 RPC 报错直接转成了标准的PathNotFound。而在options.create_if_missing = true下，RocksDB 只要从文件系统拿到PathNotFound，就认为这是一个刚创建的新库，于是心安理得地初始化。
在存储引擎与物理介质之间，任何看似简单的胶水转换代码，本质上都承载着严格的崩溃恢复因果律。早期 RocksDB 沿袭 LevelDB 的设计，把文件操作、后台线程池调度、高精度微秒时钟甚至互斥锁全部塞进单体虚基类Env中，不仅接口臃肿，更关键的是错误语义被严重抹平。直到 6.x 版本将文件与目录操作彻底剥离为独立的FileSystem，并引入携带重试状态与故障作用域的IOStatus，现代存储系统的错误分级与容错契约才真正立住。
剖析 RocksDB 从单体 Env 到正交 FileSystem 的解耦演进，走读 IOStatus
