checksum 标签归档 | 土法炼钢 · 系统与基础设施

【Ceph RADOS】BlueStore 写路径：min_alloc_size、deferred/WAL、checksum 与压缩

以 min_alloc_size 为分叉点拆解 BlueStore 的两条写路径：小写经 deferred WAL 先落 RocksDB 再后台应用到裸盘，大写直接落裸盘后原子更新 onode；说明 checksum 计算时机和压缩对分配逻辑的影响。

跟踪 BlueStore 一次读操作从 onode 缓存查询、extent map 展开、blob 物理位置定位，到 BlockDevice aio 读取和 checksum 验证的完整路径；梳理缓存架构与静默数据损坏的检测边界。

按五轴映射 Ceph 常见故障症状：slow ops（慢操作）、peering 卡死、满盘/nearfull、recovery 拖死前台、checksum/inconsistent——每轴给出核对顺序与观测入口，不粘贴伪造集群输出。

从 fsync 语义、写屏障与电源故障到静默损坏与端到端校验——建立存储栈各层丢失/损坏认知；算法选型见 checksum 篇，ZFS 实现见 zfs-integrity 篇。

深入分析存储系统中的数据完整性保障——CRC32C、xxHash、SHA-256 的性能对比，静默数据损坏的检测与防护，端到端校验架构设计

ext4 和 XFS 走的是"就地更新"路线：数据写到哪个块，就直接覆盖那个块。这条路线简单、高效，但有一个根本性的问题——如果写到一半断电，磁盘上的数据处于半新半旧的状态，文件系统就损坏了。日志（Journal）机制可以缓解这个问题，但它本质上是"先写一遍日志，再写一遍数据"，写放大不可避免。