© XXX Page 1 of 3 curvefs s3数据整理(合并碎片、清理冗余)© XXX Page 2 of 3 1. 2. 3. 1. 2. 3. 4. 5. 6. 1. 2. 背景 只考虑单客户端, 单metaserver 为了解决的问题: 客户端在对一个文件的某个部分多次写入后, 同一个chunk会产生很多版本数据; 而客户端在读的时候 而客户端在读的时候, 会需要对这些chunk进行筛选和构建, 得到有效的部分, 越是散乱的状态, 就越需要发送更多次读请求至s3. 最后导致无效旧数据的堆积和读请求性能的下降, 所以需要在合适的时候进行重叠元数据和数据的合并 原则是尽力而为, 并不能做到完美 方案 基于一下3个基础的数据结构, 2层索引 s3chuninfolist[index] = [s3chunkinfo(s)] s3chunkinfo 个inode元数据缓存失效, 重拉 写: 只是对chunkinfolist做新增, 不影响整理对原有部分的变更 删除: 已标记为删除的inode不进行整理, 已经在整理的任务不会被新的删除标记的请求打断. 如果标记删除到实际删除之间的时间间隔非常短, 并且在标记删除前已经开始了整理任务, 可能会出现边删除边整理的状态(出现概率较小) 可以在实际删除前检查当前整理的inode列表, 如果在列表

通过日志初步分析有2点原因© XXX Page 3 of 9 1.append接口目前采用先从s3 get，在内存中合并完后再put的方式，对s3操作过多 2.对于4k 小io每次都要和s3交互，导致性能非常差。 因此需要通过Cache模块解决以上2个问题。 整体设计 整个dataCache的设计思路，在写场景下能将数据尽可能的合并后flush到s3上，在读场景上，能够预读1个block大小，减少顺序读对于底层s3的访问 考虑到同一个client同一个文件同时只能一个线程进行文件写，所以在Write函数中加写锁。 3.根据请求offset，计算出对应的chunk index和chunkPos。将请求拆分成多个chunk的WriteChunk调用。 4.在WriteChunk内，根据index找到对应的ChunkCacheManager，根据请求的chunkPos和len从dataCacheMap中找到一个可写的DataCache： 获取 5. 如果有可写的DataCache，则调用Write接口将数据合并到DataCache中； ，加入到ChunkCacheManager的Map中。 如果没有可写的DataCache则new一个 5.完成后返回成功。 Read流程 1.根据请求offset，计算出对应的chunk index和chunkPos。将请求拆分成多个chunk的ReadChunk调用。 2.在ReadChun

配之后，extent的元数据量为24GiB（1PiB / 1MiB * 24，24为每个extent所占用的字节大小）。 如果同一文件在多次申请空间时，能分配连续的地址空间，则extent可以进行合并。例如，文件先后写入两次，每次写入1MiB数据，分别申请的地址空间为（100MiB，1MiB）和（101MiB，1MiB），则只需要一个ex tent进行记录即可，（0，100MiB，2MiB）。 。分配之后，相关信息如下图所示： 之前剩余的 30MiB ~ 2MiB 的extent完全分配出去，所以从level2中的list中删除。 文件inode中的extent可以将两次的申请结果进行合并，得到（0，28MiB，4MiB）。 特殊情况 新文件申请空间时，leve1中的所有bit都标记为1，即所有的块都已经预分配出去。在文件系统空间比较满的情况下，有可能会造成这个问题。此时，申请空 2. 。尽可能合并多个块分配给同一个文件。 空间回收 空间回收主要是一个extent合并的过程，有以下几种情况： 文件释放了一个完整的块，则直接将level1中对应的bit置为0。 文件释放了一小段空间，则尝试与level2中的extent进行合并。 如果合并之后是一个完整的块，则重新将level1中对应的bit置为0，同时删除该extent。 如果不能合并，则向level2中插入一个新的extent。

支持从快照回滚 • 高可用，克隆任务中断自动拉起继续克隆快照克隆服务器架构 • 基于brpc提供restful API的对外http接口 HttpService: • Serivce层面区分上层请求为同步接口调用，还是异步接口调用， 同步接口调用直接调用Core层接口实现功能，异步接口创建Task， 并交由TaskManager调度。 SnapshotService & CloneService: 使用copy-on-write  当前写请求的sn > chunk的cur_sn时触发复制  拷贝的单位是一个Page，即4KB  使用snapfile中的bitmap标记复制过的PageCHUNKSERVER端快照实现-转储内部快照 a) 打快照后未写过，未触发cow， 无snap file产生，直接读取chunk file b) 打快照后写过，触发了cow， 有snap file， 合并读取 c) 卷从未写过， 时复制原理 • 使用chunkfile的bitmap来标记写过的Page， 一个Page大小为4KB • 读请求到来时，根据bitmap中的信息， • 对于已写过的区域，从本地chunk file读 • 对于未写过的区域，从远端源chunk file读 • 之后，将两者合并返回。 • 同时把源chunk读到的数据异步写入到本地 chunk，并标记bitmap，这个过程称之为 PasteChunk

，只需要把chunkserver改成metaserver。 curvefs的topo信息的层级最终是这样： →pool ：存储池（curve的physical pool和logic pool这里合并，只保留一个pool） →zone：可用域 →server：代表着一台服务器 →metaserver：代表着一块盘© XXX Page 9 of 19 录。最后修改fs状态为INITED。© XXX Page 10 of 19© XXX Page 11 of 19 6.2、挂载fs 挂载fs的流程不变，client向mds发送mount rpc请求，mds对fs进行相应的检查，然后记录挂载点返回成功。 1、检查文件系统是否存在 2、检查fs的状态，是否是INITED状态 3、检查挂载点是否已经存在 6.3、创建文件/目录 clien vector Copyset * out 6.6、topology topology参考curve的topology的实现，由于curve的physical pool和logic pool在curvefs中合并成了一个，所以，并不能直接复用curve的topology的代码。 curve在创建logic pool的时候去创建copyset。现在集群的topo信息在mds创建好了之后，topo中并没有co

信息  元数据信息在打快照时会进行变化  MetaCache：元数据缓存  IOTracker：跟踪一个上层IO请求  IOSplitor：IO转换拆分  ChunkClient、CliClient：与Chunkserver进行通信  前者负责IO请求  后者负责获取复制组(copyset)的leader  MDSClient：负责与MDS交互，挂卸载卷、获取元数据信息 IO处理：转换、拆分、合并  元数据获取及缓存  逻辑chunk与物理chunk映射关系  物理chunk所属的复制组(copyset)  复制组所在的chunkserver列表  复制组的leader信息  Failover支持  MDS：只有主MDS才会监听端口  ChunkServer：通过raft维护复制组内的主-从关系CLIENT IO流程 用户下发一个写请求 off: off: 8M len: 16M 请求落在两个逻辑chunk上，所以 请求会被拆分成两个子请求：  ChunkIdx 1, off: 8M len 8M  ChunkIdx 2, off: 0 len 8MCLIENT IO流程 子请求由哪个chunkserver处理，依赖以 下信息：  逻辑chunk与物理chunk映射关系  物理chunk所属的复制组(copyset)

flag则在writechunk的时候会调用s3的append接口追加写到同一个block object。 3.更新inode中s3元数据的时候，现在只会将可以直接合并的S3Info进行了合并，后面需要考虑如果S3Info太大，需要进行rewrite将元数据进行重新合并 4.inode我们只更新s3Info，并不更新length，length由client在外面流程统一更新© XXX Page 11 of 11 read流程

1、client给server0发送请求：parentid 0 + name "A"，查询"A"的inodeid为100© XXX Page 13 of 24 2、client给server0发送请求：inode 100，查询的"A"的inode信息。 3、client给server1发送请求：parentid 100 + name "C"，查询"C"的inode为300 4、client给server1发送请求：inode 1、client给server0发送请求：parentid 0 + name "A"，查询"A"的inodeid为100 2、client给server0发送请求：inode 100，查询的"A"的inode信息。 3、client给server1发送请求：parentid 100 + name "C"，查询不到 4、client给server1发送请求：分配inodeid 300，创建文件C的inode。 + C → 300 删除文件：删除/A/C 1、client给server0发送请求：parentid 0 + name "A"，查询"A"的inodeid为100 2、client给server0发送请求：inode 100，查询的"A"的inode信息。 3、client给server1发送请求：parentid 100 + name "C"，查询"C"的inode为300 删除记录

响应来自其他服务器的请求，如果接受不 到消息，就变成候选人并发起一次选举。 • 时间被划分成一个个的任期，每个任期开始都是一次 选举。 • 选举成功，领导⼈会管理整个集群直到任期结束。 • 选举失败，这个任期就会没有领导⼈⽽结束。 raft选举leader raft任期RAFT协议简介 raft复制状态机 1. leader收到客户端的请求。 2. leader把请求指令记录下来，写入日志，然后并⾏发 Curve块存储 • 高性能、更稳定、易运维 • 支持NBD(network block device)、iscsi • 支持RDMA和SPDK Curve块存储架构 • client：接受用户请求。 • mds：保存元数据，包括topo信息、块设备信息、 数据分布信息等，持久化到etcd中。 • chunkserver：采用raft协议3副本的方式保存块 设备上的数据。 • snaps • chunk -> copyset -> chunk in 3 chunkserverCurve块存储RAFT应用 请求处理流程 以写请求为例： 1. Client 发送写请求给 Leader ChunkServer。 2. ChunkServer 收到请求，将请求封装成一个 log entry，提交给 raft。 3. raft模块在本地持久化 entry 的同时发送 entry

2、解析MDS的心跳response中的raft 成员变更信息，向CopysetNode发起变 更 ChunkServer架构ChunkOpRequest模块封装了对 ChunkService到达的I/O请求的实际处 理过程。请求到来时，封装一个 OpRequest，将上下文保存在里面，然 后发起Propose提交给raft，等raft apply后再执行后面的操作。 ChunkServer架构CloneManager主要负责克隆相关的功 器，统计一些IO层面和copyset层面的 一些指标，方便监控和跟踪。 ChunkServer架构并发控制层，负责对chunkserver的IO 请求进行并发控制，对上层的读写请 求安照chunk粒度进行Hash，使得不同 chunk的请求可以并发执行。 ChunkServer架构DataStore是对chunk落盘逻辑的封装。 包含chunkfile的创建、删除，以及实际 对chu ChunkServer架构LocalFileSystermAdaptor是对底层文件 系统的一层抽象，目前适配封装了ext4 文件系统的接口。 之所以要做这层抽 象，目的是隔离了底层文件系统的实 际读写请求，如果将来curve要适配裸 盘或者采用其他文件系统，可以在这 层进行适配。 ChunkServer架构CURVE基本架构 01 02 03 04 ChunkServer架构 ChunkServer核心模块