【Ceph RADOS】EC 路径：ECBackend、整条带写与 RMW 的代价模型
内容提要
Ceph的ECBackend实现中，整条带写无需读旧数据，而部分写需读改写（RMW），增加延迟。EC修复从k个存活分片重建缺失分片，网络效率优于副本池。EC池空间效率高（4+2为1.5倍），但随机小写延迟高，适合顺序大写场景如RGW。allow_ec_overwrites支持覆盖写，但RMW代价仍在。编码插件有Jerasure、ISA-L等，LRC可降低重建读取。
延伸解读
RMW 代价的量化视角
文章指出，RMW 的代价不仅在于额外的读操作，还在于读依赖带来的延迟。对于随机小写，即使 NVMe 降低了读 RTT，RMW 的读-改-写流程仍会显著增加延迟。文章强调，不应简单断言 EC 小写延迟是副本的固定倍数，而应基于具体配置（k、m、stripe_unit）和硬件实测。这提醒读者在评估 EC 池时，需关注实际工作负载下的延迟分布，而非依赖笼统的性能结论。
EC 修复的网络优势与 mClock 配额不对等
EC 修复只需读取 k 个分片并写入 1 个分片，相比副本池的整对象拷贝，网络效率更高。但文章指出，mClock 的 recovery_op 配额按操作数而非字节数限制，导致 EC 修复在相同配额下消耗更多实际带宽。这一不对等性可能影响修复速度，但官方文档未给出明确补偿建议。读者在规划 EC 池时，需考虑此因素对恢复时间的影响。
EC 池的可用性劣势与故障域设计
EC 池写入需要 k+m 个 OSD 全部存活，而副本池只需多数派存活，因此 EC 在部分故障时写可用性更低。文章建议通过 CRUSH 规则将故障域覆盖 m+1 个机架，以降低同时故障风险。这提示读者，EC 并非在所有场景都优于副本，需权衡空间效率与可用性，尤其在网络分区或节点故障频繁的环境中。
Q&A
Ceph EC池中，整条带写和读改写（RMW）有什么区别？
整条带写是指写请求覆盖整个条带（即所有k个数据块），此时Primary可以直接编码生成校验块并写入，无需读取旧数据。而读改写（RMW）发生在写请求只覆盖条带内部分数据块（W < k）时，需要先读取未修改的数据块，与新数据合并后重新计算校验块，再写回，因此增加了额外的读延迟和I/O开销。
Ceph EC池的存储开销如何计算？与三副本相比有何优势？
EC池的存储开销为(k+m)/k倍原始大小，例如4+2 EC（k=4, m=2）开销为1.5倍，而三副本开销为3倍，因此EC池空间效率更高。
Ceph EC池的修复过程是怎样的？为什么网络效率优于副本池？
EC池修复时，Primary从任意k个存活分片读取数据，通过解码重建缺失分片，然后写入新OSD。相比副本池需要拷贝整个对象，EC修复只需读取k个分片（每个分片大小为原始对象的1/k）并写入1个分片，因此网络I/O更少，效率更高。
Ceph EC池支持覆盖写吗？需要什么条件？
支持。从Luminous版本开始，通过启用allow_ec_overwrites功能，EC池可以支持覆盖写。前提是使用BlueStore后端（FileStore不支持），并且需要满足与BlueStore能力对齐的约束。启用后，EC池可作RBD后端，但随机小写仍会触发RMW，延迟较高。
Ceph EC池适合哪些场景？为什么RGW是常见生产场景？
EC池适合顺序大写、冷数据归档等场景，因为整条带写路径高效且空间节省。RGW（对象网关）是常见生产场景，因为S3/Swift对象通常是一次性大文件写入（PUT整个对象），读以完整读为主，几乎不做随机覆盖写，非常适合EC的整条带写路径。
Ceph EC池的随机小写延迟为什么高？
因为随机小写通常只覆盖条带内部分数据块，触发读改写（RMW）路径，需要先读取未修改的数据块，再合并计算校验并写回，增加了额外的读RTT和编码计算，导致延迟显著高于副本池。
Ceph EC池的编码插件有哪些？LRC有什么作用？
Ceph EC池的编码插件包括Jerasure、ISA-L、LRC和SHEC等。Jerasure是常见默认，ISA-L利用SIMD加速GF运算，LRC（局部可修复码）可降低单盘故障重建时的分片读取数，从而减少修复I/O。
Ceph EC池的降级读是什么？有什么影响？
当EC池有分片不可用但数量不超过m时（即至少k个分片存活），仍可响应读请求，但需要从k个存活分片读取数据并解码，这称为降级读。降级读比正常读延迟更高，且对剩余k个OSD产生额外I/O负担。
