Journal先写机制的取舍

Ceph OSD 早期基于文件系统实现（FileStore）时，写数据并不直接落到最终存储位置，而是先顺序写入一块独立的 journal 区域（可以是同盘的一个分区，也可以是独立 SSD），再每隔几秒把 journal 的内容批量刷到真正的后备文件系统。这种”先顺序写日志、再合并写正式存储”的两段式路径，换来的主要是延迟的改善而不是吞吐量的绝对提升，因为数据终究还要经历一次真实落盘；用 SSD 做 journal 的价值在于用它的低延迟去吸收突发写压力，给后端文件系统争取时间做合并写入。发散：这本质是用一次额外的顺序写换取随机写的合并优化，和数据库的 WAL（预写日志）解决的是同一类问题；后来的 BlueStore 直接绕开文件系统语义开销去掉了这层，也说明这个方案本身是有代价的过渡设计。