BlueStore源码分析之对象IO

前言

BlueStore中的对象非常类似于文件系统中的文件，每个对象在BlueStore中拥有唯一的ID、大小、从0开始逻辑编址、支持扩展属性等，因此对象的组织形式，类似于文件也是基于Extent。

稀疏写

我们知道一个文件的逻辑空间上是连续的，但是真正在磁盘上的物理空间分布并不一定是连续的。同时我们也会使用lseek系统调用，使得文件偏移量大于文件的长度，此时再对文件写入，便会在文件中形成一个空洞，这些空洞中的字节都是0。空洞是否占用磁盘空间是有文件系统决定的，不过大部分的文件系统ext4、xfs都不占磁盘空间。我们称部分数据是0同时这部分数据不占磁盘空间的文件为稀疏文件，这种写入方式为稀疏写。

BlueStore中的对象也支持稀疏写，同时支持克隆等功能，所以对象的数据组织结构设计的会相对复杂一点。

名词解释

•Collection：PG在内存的数据结构。
•bluestore_cnode_t：PG在磁盘的数据结构。
•Onode：对象在内存的数据结构。
•bluestore_onode_t：对象在磁盘的数据结构。
•Extent：一段对象逻辑空间(lextent)。
•extent_map_t：一个对象包含多段逻辑空间。
•bluestore_pextent_t：一段连续磁盘物理空间。
•bluestore_blob_t一片不一定连续的磁盘物理空间，包含多段pextent。
•Blob：包含一个bluestore_blob_t、引用计数、共享blob等信息。

Onode结构

BlueStore的对象内部结构如下图：

BlueStore的每个对象对应一个Onode结构体，每个Onode包含一张extent-map，extent-map包含多个extent(lextent)，每个extent负责管理对象内的一个逻辑段数据并且关联一个Blob，Blob包含多个pextent，最终将对象的数据映射到磁盘上

onode

数据结构主要包含两部分：内存数据结构、磁盘数据结构。
Onode本身和FileStore的对象一样，主要包含四部分：数据、扩展属性、omap头部、omap条目。
omap和扩展属性很类似，只不过扩展属性大小有限制，omap没有限制。BlueStore把扩展属性和Onode一起保存，omap分开保存。

// 内存数据结构
struct Onode {
	// reference count
	std::atomic_int nref;
	
	// onode 对应的PG
	Collection *c;
	
	// onode磁盘数据结构
	bluestore_onode_t onode;
	
	// 有序的Extent逻辑空间集合，持久化在RocksDB。lexetnt--->blob
	//
	// 由于支持稀疏写，所以extent map中的extent可以是不连续的，即存在空洞。
	// 也即前一个e