整体架构
bluestore的诞生是为了解决filestore自身维护一套journal并同时还需要基于系统文件系统的写放大问题，并且filestore本身没有对SSD进行优化，因此bluestore相比于filestore主要做了两方面的核心工作：
- 去掉journal，直接管理裸设备
- 针对SSD进行单独优化
bluestore的整体架构如下图所示：
通过Allocator实现对裸设备的管理，直接将数据保存到设备上；同时针对metadata使用RocksDB进行保存，底层自行封装了一个BlueFS用来对接RocksDB与裸设备。
模块划分
核心模块
- RocksDB： 存储预写式日志、数据对象元数据、Ceph的omap数据信息、以及分配器的元数据（分配器负责决定真正的数据应在什么地方存储）
- BlueRocksEnv： 与RocksDB交互的接口
- BlueFS： 小的文件系统，解决元数据、文件空间及磁盘空间的分配和管理，并实现了rocksdb::Env 接口(存储RocksDB日志和sst文件)。因为rocksdb常规来说是运行在文件系统的顶层，下面是BlueFS。 它是数据存储后端层，RocksDB的数据和BlueStore中的真正数据被存储在同一个块物理设备
- HDD/SSD： 物理块设备，存储实际的数据
rocksdb本身是基于文件系统的，不是直接操作裸设备。它将系统相关的处理抽象成Env，用户可用实现相应的接口（rocksdb默认的Env是PosixEnv，直接对接本地文件系统）。BlueRocksEnv是bluestore实现的一个类，继承自rocksdb::EnvWrapper，来为rocksdb提供底层系统的封装。
为了对接BlueRocksEnv，实现了一个小的文件系统BlueFS，只实现rocksdb Env需要的接口。所有的元数据的修改都记录在BlueFS的日志中，也就是对于BlueFS，元数据的持久化保存在日志中。在系统启动mount这个文件系统时，只需replay日志，就可将所有的元数据都加载到内存中。BluesFS的数据和日志文件都通过块设备保存到裸设备上（BlueFS和BlueStore可以共享裸设备，也可以分别指定不同的设备）。
bluestore不使用本地文件系统，直接接管裸设备，并且只使用一个原始分区，HDD/SSD所在的物理块设备实现在用户态下使用linux aio直接对裸设备进行I/O操作。由于操作系统支持的aio操作只支持directIO，所以对BlockDevice的写操作直接写入磁盘，并且需要按照page对齐。其内部有一个aio_thread 线程，用来检查aio是否完成。其完成后，通过回调函数aio_callback 通知调用方。
缓存模块
Bluestore实现了自己的缓存机制，定义了structure ：OnodeSpace，用来map 到内存中的ONODE；BufferSpace，用来map 块信息blob，每个blob都在bufferSpace中缓存了状态数据。二者在缓存中依照LRU的方式决定生命周期。
FreelistManager模块
FreelistManager用来映射磁盘的使用信息，最初实现是采用k-v的方式来存储对应的磁盘块的使用情况，但是由于更新数据时需要修改映射，需要线程锁来控制修改，而且这种方式对内存消耗很大；后续修改为bitmap的映射方式，设定一个offset来以bitmap的方式map多个block使用信息，使用XOR计算来更新块的使用情况，这种方式不会出现in-memory 状态。
Allocator模块
用来委派具体哪个实际存储块用来存储当前的object数据；同样采用bitmap的方式来实现allocator，同时采用层级索引来存储多种状态，这种方式对内存的消耗相对较小，平均1TB磁盘需要大概35M左右的ram空间
bluestore元数据
在之前的存储引擎filestore里，对象的表现形式是对应到文件系统里的文件，默认4MB大小的文件，但是在bluestore里，已经没有传统的文件系统，而是自己管理裸盘，因此需要有元数据来管理对象，对应的就是Onode，Onode是常驻内存的数据结构，持久化的时候会以kv的形式存到rocksdb里。
在onode里又分为lextent，表示逻辑的数据块，用一个map来记录，一个onode里会存在多个lextent，lextent通过blob的id对应到blob（bluestore_blob_t ），blob里通过pextent对应到实际物理盘上的区域（pextent里就是offset和length来定位物理盘的位置区域）。一个onode里的多个lextent可能在同一个blob里，而一个blob也可能对应到多个pextent。
另外还有Bnode这个元数据，它是用来表示多个object可能共享extent，目前在做了快照后写I/O触发的cow进行clone的时候会用到。
I/O读写映射逻辑
写I/O处理
到达bluestore的I/O的offset和length都是对象内（onode）的，offset是相对于这个对象起始位置的偏移，在_do_write里首先就会根据最小分配单位min_alloc_size进行判断，从而将I/O分为对齐和非对齐的。当一个写请求按照min_alloc_size进行拆分后，就会分为对齐写，对应到do_write_big，非对齐写（即落到某一个min_alloc_size区间的写I/O（对应到do_write_small）。
- do_write_big
对齐到min_alloc_size的写请求处理起来比较简单，有可能是多个min_alloc_size的大小，在处理时会根据实际大小新生成lextent和blob，这个lextent跨越的区域是min_alloc_size的整数倍，如果这段区间是之前写过的，会将之前的lextent记录下来便于后续的空间回收。
- do_write_small
在处理落到某个min_alloc_size区间的写请求时，会首先根据offset去查找有没有可以复用的blob，因为最小分配单元是min_alloc_size，默认64KB，如果一个4KB的写I/O就只会用到blob的一部分，blob里剩余的还能放其他的。
读I/O的处理
读I/O请求的处理时也是通过寻找相关联的lextent，可能会存在空洞的情况，即读到未写过的数据，这部分就直接补零。
总结
从BlueStore 的设计和实现上看，可以将其理解为用户态下的一个文件系统，同时使用RocksDB来实现BlueStore所有元数据的管理，简化实现。
对于整块数据的写入，数据直接以aio的方式写入磁盘，再更新RocksDB中数据对象的元数据，避免了filestore的先写日志，后apply到实际磁盘的两次写盘。同时避免了日志元数据的冗余存储占用，因为传统文件系统有他们自己内部的日志和元数据管理机制。
对于随机IO，直接WAL的形式，写入RocksDB 高性能的KV存储中。
--------------------- 本文来自 OshynSong 的CSDN 博客 ，全文地址请点击：https://blog.csdn.net/u010487568/article/details/79572390?utm_source=copy