of 11 Curve文件系统空间分配方案（基于块的方案，已实现）© XXX Page 2 of 11 背景 本地文件系统空间分配相关特性 局部性 延迟分配/Allocate-on-flush Inline file/data 空间分配 整体设计 空间分配流程 特殊情况 空间回收 小文件处理 并发问题 文件系统扩容 接口设计 RPC接口 空间分配器接口 背景 根据 ，文件系统基 ，文件系统基于当前的块进行实现，所以需要设计基于块的空间分配器，用于分配并存储文件数据。 CurveFS方案设计（总体设计，只实现了部分） 本地文件系统空间分配相关特性 局部性 尽量分配连续的磁盘空间，存储文件的数据。这一特性主要是针对HDD进行的优化，降低磁盘寻道时间。 延迟分配/Allocate-on-flush 在sync/flush之前，尽可能多的积累更多的文件数据块才进行空间分配，一方面可以提高局部性，另一方面可以降低磁盘碎片。 几百字节的小文件不单独分配磁盘空间，直接把数据存放到文件的元数据中。 针对上述的本地文件系统特性，Curve文件系统分配需要着重考虑 。 局部性 虽然Curve是一个分布式文件系统，但是单个文件系统的容量可能会比较大，如果在空间分配时，不考虑局部性，inode中记录的extent数量很多，导致文件系统元数据量很大。© XXX Page 3 of 11 假如文件系统大小为1PiB，空间分配粒度为1M

S3Adaptor（一个封装了s3 client的接口层）与S3交互，存取s3 中的对象。 SnapshotDataStore: • SnapshotCloneMetaStore负责管理快照和克隆任务等元数据， 通过调用etcdclient，与etcd存储交互，存取etcd中的快照和克隆 元数据。 SnapshotCloneMetaStore: • CurveClient封装了Client接 久化任务元数据到etcd，开始执行克隆 任务。 • 2. 调用mds接口创建clone卷信息，该 clone卷是个临时卷，位于/clone目录下。 • 3. 调用mds接口为目的卷分配空间。 • 4. 根据目的卷的分配信息，调用 chunkserver接口创建CloneChunk。 • 5. 更新克隆卷状态为metaInstalled。 • 6. 发起ChunkServer数据拷贝 • 7 chunk chunkserver meta object data object data object S3 Snap Task etcd MDS client 2.创建克隆卷 3.分配卷空间 7.拷贝数据 datastore metastore http service clone Task user 快照、克隆元数据 SnapshotCloneServer 1.发起克隆

–Busy poll下不要开启，可能导致电耗过高、cpu降速40 Ucp Worker ●创建UcpWorker，封装ucp worker和逻辑。 ●是整个ucp实现RDMA的核心。 ●系统可以有多个worker，共享使用一个UcpContext。 ●不同的连接分配到不同的worker,一般情况下只需要一个worker足够应付网络通讯。 ●worker逻辑在一个pthread中运行。41 UcpConnection ●封装ucp_ep ●支持读写接口 – ssize_t Read(butil::IOBuf *out, size_t n); – ssize_t Write(butil::IOBuf *buf); – ssize_t Write(butil::IOBuf *data_list[], int ndata);49 UcpWorker的实现 ●封装 ucp_worker_h ucp_worker_h ●一个UcpWorker对用多个UcpConnection，由UcpCm分配。 ●在pthread运行，busy poll or wait mode。50 UcpWorker实现 提供Accept51 UcpWorker的实现 ●提供Connect。52 UcpWorker的实现 ●提供Release Connection。 –在UcpCm决定关闭连接时53 UcpWorker的实现

CopySetService。创建copyset等操 作 • RaftService。Braft内置的service， 完成raft成员之间的选举，日志复制， 安装快照等操作。 ChunkServer架构CopysetNode封装了braft的Node，并 实现了braft的状态机，完成与raft的交 互。详细交互流程后面展开。 CopysetNodeManager负责管理 CopysetNode的创建、初始化、删除等 2、解析MDS的心跳response中的raft 成员变更信息，向CopysetNode发起变 更 ChunkServer架构ChunkOpRequest模块封装了对 ChunkService到达的I/O请求的实际处 理过程。请求到来时，封装一个 OpRequest，将上下文保存在里面，然 后发起Propose提交给raft，等raft apply后再执行后面的操作。 ChunkSer chunk的请求可以并发执行。 ChunkServer架构DataStore是对chunk落盘逻辑的封装。 包含chunkfile的创建、删除，以及实际 对chunk的读写，chunk基本cow的快照， 克隆chunk的管理等等。 ChunkServer架构LocalFileSystermAdaptor是对底层文件 系统的一层抽象，目前适配封装了ext4 文件系统的接口。 之所以要做这层抽 象，目的是隔离了底层文件系统的实

chunkserverCurve块存储RAFT应用 请求处理流程 以写请求为例： 1. Client 发送写请求给 Leader ChunkServer。 2. ChunkServer 收到请求，将请求封装成一个 log entry，提交给 raft。 3. raft模块在本地持久化 entry 的同时发送 entry 给其 他副本（ChunkServer）。 4. 本地持久化 log entry mds：保存元数据，包括topo信息、文件系统信 息、元数据分布信息等，持久化到etcd中。 • metaserver：采用raft协议3副本的方式保存文 件文件的元数据，包括inode，dentry，文件的 空间分配信息。 • 数据集群：采用外部存储，S3或者Curve块存储，保 存写入文件的数据。Curve文件存储RAFT应用 基于rocksdb的存储引擎 • 要求存储的元数据的大小不超过内存的大小 • 文件时会调用fallocate为文件预分配固定大小的空间，但是即便fallocate以后，在写文件未写过的块 时仍需要更改元数据，存在一定的IO放大。 解决思路： 直接使用覆盖写过一遍的文件。由于chunk大小固定，预先生成一批被写过的固定大小文件。创建 chunk文件或快照文件时直接从预分配的文件池中获取进行重命名，删除chunk时再将文件重命名放到 预分配池中，这个预分配池就是chunkfile pool。

bject。 S3-allocator模块：负责分配s3-object唯一标识。© XXX Page 3 of 11 整体思路 curvefs对接s3和对接volume主要的区别在于数据持久化和空间分配部分，而元数据的操作尽量保持统一。因此我们涉及到修改client的流程主要在read/write/flush，以及空间分配申请（s3不需要释放空间，可 直接删除对应s3 object） 在将这些chunks按照offset进行大小进行排序，方便处理后面的read操作。 3.将read的offset，len和s3info可能交互的场景分别进行处理，分别获取要读取的每个S3ChunkInfo的offset len，封装到request中，具体可见代码的处理逻辑。 4.根据request进一步获取到s3 object去读取对象，将结果保存在response中。 5.最后根据所有的response将buff整合，返回给上层

复制组的leader信息CLIENT IO流程 逻辑chunk与物理chunk映射关系 物理chunk所属的复制组(copyset)  由MDS分配并持久化，client拆分用户请 求时会获取并进行缓存  为了减少元数据量，MDS一次会连续分配 1G范围内的映射关系，称为SegmentCLIENT IO流程 复制组所在的chunkserver列表  chunkserver心跳定期上报给MDS 3. 从Chunkserver获取复制组leader信息 4. 将请求发往leader节点CLIENT IO线程模型 用户线程 1. 用户调用接口，发起IO请求 2. AioWrite将请求封装成io task并放入任务队列 3. 放入任务队列后，异步请求发起成功，返回用户 IO拆分线程 4. 从任务队列取出任务后进行拆分 5. 拆分过程依赖元数据，可能会通过MDSClient向

4.2.5.1 事件一先发生 4.2.5.2 事件二先发生 4.2.6 异常情况4：Etcd集群的follower节点异常 4.2.7 各情况汇总 1. 需求 mds是元数据节点，负责空间分配，集群状态监控，集群节点间的资源均衡等，mds故障可能会导致client端无法写入。 因此，mds需要做高可用。满足多个mds, 但同时只有一个mds节点提供服务，称该提供服务的mds节点为主，等 clientv3的concurrency介绍 3.1 etcd clientV3的concurrency模块构成© XXX Page 3 of 30 etcd clientV3的concorrency模块对election进行了封装，首先对该模块做一个详细的介绍。 定义了 的接口： Election type Election struct { session *Session // etcd serversession

李小翠 初稿(背景，调研，架构设计) 2021-03-30 李小翠 增加快照部分 2021-04-13 李小翠、陈威 补充元数据数据结构 2021-04-19 李小翠、吴汉卿、许超杰等 补充文件空间分配，讨论与确认 背景 调研 开源fs 性能对比 可行性分析 方案对比 对比结论 架构设计 卷和文件系统 元数据架构 文件系统快照 方案一：文件/目录级别快照 方案二：文件系统快照 关键点 现相对简单，并且对于需要备份的场景也是够用的。从可解决程度和解决的必要性考虑，选择第二种方 案。 关键点 mds volume 文件空间管理 文件系统的元数据所在的copyset分配策略（前期可以考虑都分配到同一个copyset上） metaserver inode/dentry的内存组织形式 数据持久化 client curvefs 的 client 开发 快照逻辑 各接口实现元数据交互流程 文件空间管要解决的问题是：一个文件的数据如何存储？物理空间如何分配给不同的文件，如何从不同的文件回收？从这两个角度出发，分别调研了以下系统的空间管理策略： bluestore: CurveFS空间分配调研#bluestore chubaofs: CurveFS空间分配调研#chubaofs moosefs: moosefs空间分配调研 polarfs: CurveFS文件存储设计参考方案（元数据存储在卷上方案）#PolarFS

curve块设备的copyset是在空间预分配的时候就确定了，每次预分配1GB的空间，然后这1GB的空间每个chunk对应的copyset在预分配的时候已经确定。后续的读写的操作直接去对应的copyset上去进行读写。这个 分配copyset方式，并不适合curvefs的元数据。这种分配方式是提前分配了一批空间，即使用户只需要写4KB数据，也一次性分配1GB的空间。而curvefs的元数据，并不 能一次申请一批在client端，而是每次都需 要去metaserver上去进行分配。 这里需要重新考虑curvefs的copyset和fs的元数据分片的对应关系。© XXX Page 3 of 19 2、chubaofs的元数据管理 chubaofs（补充链接）的元数据也是采用的raft的方式进行管理，可以借鉴一下chubaofs的元数据的分片策略。 通过分析chubaofs的源代码。ch true } return } 2.2、meta partition的管理 当这个partition inode用完了怎么办？当partition管理的分片的inode id分配完了。 ，但是dentry可以继续。而且meta 这个partition会变成readonly状态，不再接收新的inode的申请 partition还会自动的分裂， 是把volume的最后一个pa