从SPDK Blobstore到 Blob FS

前言

SPDK通过绕过内核(kernel bypass)的方案，构筑了用户态驱动，并利用异步轮询、无锁机制等，极大地提升了I/O性能。然而，正因为采用了kernel bypass的设计，使得原本内核中的文件系统不能使用。因此，SPDK提供了Blobstore用来支持上层存储服务，并基于此封装了Blob FS(Blob Filesystem)文件系统。

当前Blob FS实现了对RocksDB的集成测试(对RocksDB的集成可参考[1])，由于前文^[2]已经对Blobstore和Blob FS做过一些介绍，本文就续接前文，对其细节进行补充。

Blobstore设计框架

图1展示了Blobstore主要存储结构的层次关系以及调用关系，可以看到Blobstore位于Bdev层之上。在SPDK的设计中，Bdev作为子系统，用来支持各个块设备，并提供了通用块设备的抽象，其作用可以看作内核中通用块层，它屏蔽了底层的具体实现，而对外提供统一的接口，例如在Bdev子系统中实现了NVMe Bdev模块可以支持对NVMe设备的I/O操作。整个Blobstore的核心代码位于spdk/lib/blob/blobstore.c文件中。

图1. RockDB调用关系和Blobstore存储结构

SPDK提供的Blobstore存储框架，其本质是维护blob分配管理，blob的概念类似文件，但并不与文件等同，本身并不满足POSIX接口，然而Blobstore可以作为底层存储基础用来支持更上层的存储业务，例如下文将提到的Blob FS以及逻辑卷管理等等。整个Blobstore的设计围绕异步与并行，即对多个Blob采用的是无锁、异步并行的I/O操作。而为了支撑逻辑卷管理^[5]，需要不同的操作粒度以及动态空间的划分，Blobstore定义了层次的存储单元结构，整个结构自上而下分为blob，cluster，page，logical block。

其中，logical block是存储设备本身的存储单元大小，通常一个logical block的大小为512B或者4KB，整体空间可以划分为0~N个logical block；page由一个或多个连续的logical block组成，page的大小通常为4KB，这是由于 Blobstore的原子操作主要依赖后端设备能支持的粒度，而NVMe SSD通常提供原子操作粒度为4KB；多个连续的page将构成我们的cluster，同样整个cluster的编号也是连续的，cluster的大小通常被定义为1MB，即由256个连续的page组成，可以发现cluster以下均是由连续存储单元组成，这样的设计出于性能的考虑，在进行I/O操作时，通过起始地址，长度以及偏移量就可以很快计算得到对应的存储位置；在cluster之上则是blob，存放在blob中的cluster并不要求一定连续，这与逻辑卷管理的动态空间划分有关，Blobstore将blob放在了blob list中进行统一的维护。

针对上层的业务，Blobstore屏蔽了cluster、page以及logical block的设计细节，仅暴露出blob单元。更多针对Blobstore存储单元的说明，可参考文献^[3]，这里仅强调一下cluster 0的作用，它包含了Blobstore所有信息以及元数据，实现了对blob的分配、查找等功能的依赖，其主要结构以及实现方式可参考文献^[2]，这里不再赘述。另外，出于性能的考虑Blobstore维护了两组元数据，其中一组保留在内存中，只有当程序显示调用或者正确关闭Blobstore时，才会将两组元数据进行同步。每组元数据的组成分为全局元数据和每个blob中的元数据，通常情况下，当Blobstore正常关闭时，元数据将保持一致&#x