FileStore的journal双写放大问题

FileStore把Object存成普通文件，借助Linux文件系统实现存储，但一个简单的put操作在ObjectStore层面要求touch、setattrs、write、omap_setkeys四步是原子性的一个事务，而底层文件系统本身并不支持这种跨系统调用的事务原子性。为了补上这个缺口，FileStore引入journal：先把整个事务写进journal，再去执行真实的文件系统操作，成功后才从journal里删除这条记录，一旦中途崩溃就用journal里没删除的记录重做。这样虽然拿到了事务原子性，代价是任何写入都要先写journal再写文件系统，数据量至少翻倍，再叠加XFS/Btrfs自身也带journal的写放大，journal很容易成为整个ObjectStore的性能瓶颈。发散：这是”通用文件系统不提供的能力，只能靠上层自己实现一份日志来补”的典型案例，凡是借助通用组件实现专用语义时，都要留意这类”补丁层”往往会成为新的性能瓶颈——真正的根治方案通常是绕开通用组件、自己直接管理底层资源，这正是后面BlueStore要走的路。