过去十年里，Ceph 一直是在本地文件系统的基础上实现。这个是目前大部分分布式文件系统的选择，因为这样可以利用这些实际环境验证过的代码。然而，Ceph 的经验告诉我们这么做也是有代价的——首先，实现一个零开销的事务机制会很困难；其次，本地的元数据性能会极大影响分布式系统；第三支持新的存储硬件会变得很慢。 Ceph 通过一个新存储后端 BlueStore 来解决这些问题，BlueStore 设计为直接在块设备上运行。在其面世的短短两年里，BlueStore 已经被 70% 的生产客户所采用。通过运行在用户态和对 IO 栈的完全控制，BlueStore 实现了高效的元数据空间和数据校验、EC 数据快速覆写、在线压缩、减少了性能的波动而且避免了一系列本地文件系统的隐患（pitfalls）。最后，通过 BlueStore 还让支持一些原本不支持的存储硬件成为可能。 介绍 后端存储采用文件系统的好处： 无需自行解决数据持久和块分配的问题 提供熟悉的 POSIX 接口和抽象（文件、目录） 可以使用ls、find这些常用工具来管理 Ceph 开发 BlueStore 几个主要原因： 难以在现有文件系统上实现高效的事务操作。 现有的实现要么有很高的性能损失、要么功能有限、要么接口或实现过于复杂，总之都没有直接集成到文件系统里。 Ceph 使用用户态的 WAL 来实现，或者一个支持事务的 KV 存储，但性能都不能满意 本地文件系统的元数据性能极大影响分布式层。具体来说，Ceph 需要快速枚举（enumerate）有几百万条目的目录，但 Btrfs 和 XFS 都支持的不够好；如果拆分目录（directory splitting ）来减小一个目录内的文件数量，这个操作在文件系统上有成本极大，会拖垮整个系统的性能 因为文件系统本身的过于成熟，会导致它对新存储硬件的支持非常慢。例如用来解决 HDD 容量问题的 SMR，用来解决 SSD 的 FTL 层性能损失的 ZSS SSD 都难以支持 […]