BlueStore去journal直接管理裸设备

[[FileStore的journal双写放大问题]]的根源是把ObjectStore建在通用文件系统之上，只能靠journal这个补丁去凑事务原子性。BlueStore干脆放弃通用文件系统，用户态直接实现BlockDevice和Allocator来管理裸设备的空间分配，元数据则以Key/Value形式存进RocksDB——但RocksDB本身依赖文件系统运行，于是BlueStore又为它量身定制了一个极简文件系统BlueFS。这样一来事务的原子性由KVDB自身的事务机制提供，不再需要额外的journal双写，同时针对固态硬盘的特性做了专门优化，从架构根子上解决了FileStore的写放大和机械盘导向设计的问题。发散：BlueStore的做法印证了一个规律——当一个通用组件（文件系统）成为专用场景下的性能天花板时，比起在它之上叠更多补丁，直接绕开它自己实现一套更贴合场景的最小化组件，往往才是真正的出路，代价是要重新造轮子并自己负责这些底层机制的正确性。