类型的文件被一个客户端正在打开，而同时有另一个客户端要删除它时，此时master对该文件节点的处理是并不立即删除该文件而是设置为TYPE_RESERVED类型并将该fsn ode连接到reserved链表中，使该文件虽然已经从文件树中删除掉，但因为另一个正在打开该文件的客户端因为持有该节点inodeid,所以不影响它对该文件的读写操作，当所有客户端都关闭该文件后，该文 件节点才会从 被清除。 reserve reserve 使用了session机制，记录client端的open状态 通过META文件系统访问reserve 使用CUTOMA_FUSE_RESERVED_INODES消息保持和释放inode 实现了Timer，定期判断是否还有session，如果没有client打开，则进行清理。 优点： 通过meta文件系统来管理trash，更为优雅。© XXX Page 8 of 15 1. ，目录由于是nlink从2开始，当目录的nlink=2时，连续减两次到0。 freelist会被定期清理，清理时筛选出超过7天的inodeid，将其从inode tree和free list中移除。 chubaofs中实现了forget接口：首先client端，在删除inode时，如果判断到nlink减到0，则加入client端维护 。forget接口执行时，判断inode是否在 中，如果在Orpha

• 数据存储 • 副本一致性，raft • 客户端 Client • 对元数据增删改查 • 对数据增删改查 • 快照克隆服务器 • 快照 • 克隆快照和克隆的特点 • 快照的定义 快照是云盘数据在某个时刻完整的只读拷贝，是一种便捷高效的数据容灾手段， 常用于数据备份、制作自定义镜像、应用容灾等。 • 快照的特点 • 转储到s3对象存储 • 异步转储快照，底层使用copy-on-write技术，读写不影响转储 Server交互。 CurveClient: • 负责管理快照和克隆源卷的引用计数。 SnapshotRef & CloneRef：快照总体流程 • 1.用户发起快照，生成快照任务，并持久化到 etcd，开始执行快照任务。 • 2.在curve中创建内部快照，并返回快照信息， 然后将快照信息更新到etcd。此时，即返回用 户快照成功，可以进行读写。 • 3.向mds查询快照的元数据，转储快照元数据 ChunkFile。CHUNKSERVER端快照实现-SNAPFILE 字段 类型 说明 version uint8_t 文件格式协议 版本号 demaged bool 损坏标记 sn uint64_t 快照版本号 bits uint32_t 位图的位数 bitmap char[] 位图 crc uint32_t 上述字段的crc 校验码 padding / 填0，以补足 4KBCHUNKSERVER端快照实现-写时复制原理

6、详细设计 6.1 创建fs 6.2、挂载fs 6.3、创建文件/目录 6.4、open流程 6.5、读写流程 6.6、topology 7、工作评估 7.1 client端 7.2 mds端 7.3 metaserver端 metaserver 子模块拆分 8、inode和dentry的内存估算 8.1 一台机器上能存放多少个inode和dentry 8.2 一台机器上建议的copyset数量 分配copyset方式，并不适合curvefs的元数据。这种分配方式是提前分配了一批空间，即使用户只需要写4KB数据，也一次性分配1GB的空间。而curvefs的元数据，并不能一次申请一批在client端，而是每次都需 要去metaserver上去进行分配。 这里需要重新考虑curvefs的copyset和fs的元数据分片的对应关系。© XXX Page 3 of 19 2、chubaofs的元数据管理 *btree.BTree rwPartitions []*MetaPartition …… 3、curvefs的copyset和fs的对应关系 curvefs的元数据的分片，需要考虑到在创建inode的时候，其实是不知道inodeid的，在创建完成之后，才有inodeid。inodeid的分配最好下放到各个分片去进行处理。否则整个集群的inode都去一个地方获取id会 造成巨大的锁开销，这个是不能接受的。

新版本Client/NEBD性能优化CURVE基本架构 • 元数据节点 MDS • 管理和存储元数据信息 • 感知集群状态，合理调度 • 数据节点 Chunkserver • 数据存储 • 副本一致性，raft • 客户端 Client • 对元数据增删改查 • 对数据增删改查 • 快照克隆服务器CURVE基本架构 01 02 03 04 Client总体介绍 热升级NEBD总体介绍 新版本Client/NEBD性能优化 将请求发往leader节点CLIENT IO线程模型 用户线程 1. 用户调用接口，发起IO请求 2. AioWrite将请求封装成io task并放入任务队列 3. 放入任务队列后，异步请求发起成功，返回用户 IO拆分线程 4. 从任务队列取出任务后进行拆分 5. 拆分过程依赖元数据，可能会通过MDSClient向 MDS获取 6. 拆分成的子请求放入队列CLIENT IO线程模型 IO分发线程 7 重试请求还是返回OVERLOAD，造成用户IO请求一直 无法返回。 加入睡眠时间指数退避，并加入一个随机值，避免sleep后大量重试又碰撞到一起。 RPC超时： 请求在chunkserver端处理请求处理时间长，导致请求的返回时间超过了预期的RPC超时时间。 这种情况下，如果重试请求的RPC超时时间不发生变化，也有可能会重复上述流程，导致用户IO请求迟迟 未能返回。所以，在这种情况下，

接口设计 Cache设计 时间 作者 内容 2021-04-27 许超杰 初稿 背景 CurveFS初步设计见 ， 目前需细化Client端设计 CurveFS方案设计（总体设计，只实现了部分） 概述 CurveFS client 向上提供两层接口，分别是© XXX Page 3 of 11 对接fuse，提供通用文件系统接口。对于 ock），块分配器（bitmap）和root inode所在的copyset、 metaserver ip等信息 去metaserver获取文件系统信息（super block），缓存到client端。 destroy void (*destroy) (void *userdata); 清理init缓存的文件系统信息。 lookup void (*lookup) (fuse_req_t req node结构（包括file length）; inode修改需要持久化到底层并修改本地cache； 调用curve client接口，写curve卷对应[offset，len] 数据。 （这里涉及到一个问题，是否从fuse下来的请求是4k对齐的，如果不是，那么这里还需要修改为read merge write，即读出未对齐缺少的部分，然后整个[offset,len] 调用curve client写）;

02 03 MDS各组件详细介绍 Q&A基本架构 • 元数据节点 MDS 管理元数据信息 收集集群状态信息，自动调度 • 数据节点 Chunkserver 数据存储 副本一致性 • 客户端 Client 对元数据增删改查 对数据增删改查 • 快照克隆服务器MDS各个组件 MDS是中心节点，负责元数据管理、集群状态收集与调度。MDS包含以下几个部分： • Topology: 管理集群的 Curve 系统引入 CopySet 有几个目的： 1. 减少元数据量：如果为每个Chunk去保存复制组成员关系，需要至少 ChunkID+3×NodeID=20 个byte，而如 果在Chunk到复制组之间引入一个CopySet，每个Chunk可以用ChunkID+CopySetID=12个byte。 2. 减少复制组数量：如果一个数据节点存在 256K个复制组，复制组的内存资源占用将会非常恐怖；复制组之 下，心跳的流量将会非常大；而引入CopySet的概念之后，可以以CopySet的粒度进行探活、配置变更，降低 开销。 3. 提高数据可靠性：在数据复制组过度打散的情况下，在发生多个节点同时故障的情况下，数据的可靠性会受 到影响。引入CopySet，可提高分布式存储系统中的数据持久性，降低数据丢失的概率。COPYSET ChunkServer，Copyset和Chunk三者之间的关系如下图： Mds在分配空间时，轮流

© XXX Page 1 of 9 Curvefs-S3 本地写缓存盘方案© XXX Page 2 of 9 背景 方案设计 主要数据结构定义 方案设计思考 POC验证 背景 当前，s3客户端在写底层存储的时候是直接写入远端对象存储，由于写远端时延相对会较高，所以为了提升性能，引入了写本地缓存盘方案。也即要写底层存储时，先把数据写到本地缓存硬盘，然后再把本地缓存 硬盘中的数据异步上传到远端对象存储。 S3模块接收到写入后先写入写内存缓存页，如果满足持久化的条件后，那么则准备持久化。 如果未配置本地硬盘作为写缓存，那么直接持久化到远端的对象存储；如果配置了本地硬盘作为写缓存，那么则尝试先写入本地硬盘写缓存目录。 写本地硬盘缓存目录之前先判断缓存目录容量是否已达到阈值，如果已经达到阈值，那么则直接写入到远端对象存储；否则，则写入到本地硬盘写缓存目录中。文件写入本地硬盘写缓存目录后，从本地硬盘读目录© XXX Page 4 of 到远端对象存储集群，上传成功后，删除本地写缓存目录中的对应文件。 同时，缓存清理模块会定时检查本地硬盘缓存目录容量情况，如果容量已经达到阈值了，则进行文件的清理工作。 另外，异常管理模块处理客户端挂掉后的文件重新上传问题。 主要数据结构定义 class DiskCacheManagerImpl : public DiskCacheManager{ public: DiskCacheManagerImpl();

2. 3. 1. 2. 3. 4. 5. 6. 1. 2. 背景 只考虑单客户端, 单metaserver 为了解决的问题: 客户端在对一个文件的某个部分多次写入后, 同一个chunk会产生很多版本数据; 而客户端在读的时候, 会需要对这些chunk进行筛选和构建, 得到有效的部分, 越是散乱的状态, 就越需要发送更多次读请求至s3. 最后导致无效旧数据的堆积和读请求性能的下降 1，chunkid为上一步获取的chunkid，为需要新增的obj - 老的obj为全部需要删除的部分 应用变更 - 先读写新增的s3 objects列表, 由于新增了version字段, 不会涉及到覆盖老的对象 - 加锁, 增量的更新inode的s3chunkinfolist, 保证原子更新, 更新失败回退新增数据 - 等待N秒, 保证mds已经告知client缓存失效, 需要更新为新的s3chunkinfolist 2. 1. 2. 1. 2. 需要进行一个merge的步骤 在做变更时如果有其他op可能会产生的冲突: 读: 在执行变更删除原来的s3 object时, 执行读的客户端的缓存可能还是原有的chunkinfolist, 可能会去读已经删除的object, 这种时候读会失败 可以使用双重保证 读失败的时候retry, 或许可以重拉metadata 整理后, mds在

6 异常情况4：Etcd集群的follower节点异常 4.2.7 各情况汇总 1. 需求 mds是元数据节点，负责空间分配，集群状态监控，集群节点间的资源均衡等，mds故障可能会导致client端无法写入。 因此，mds需要做高可用。满足多个mds, 但同时只有一个mds节点提供服务，称该提供服务的mds节点为主，等待节点为备；主节点的服务挂掉之后，备节点能启动服务，尽量减小服务中断的时间。 live)指的是给一个key设置一个有效期，到期后key会被自动删掉。这在很多分布式锁的实现上都会用到，可以保证锁的实时性和有效性。CAS(Atomic Compare-and-Swap)指的是在对key进行赋值的时候，客户端需要提供一些条件，当这些条件满足后才能赋值成功。 3. etcd clientv3的concurrency介绍 3.1 etcd clientV3的concurrency模块构成© XXX Page server维持租约。这里涉及到租约的时间 LeaseTime，租约KeepAlive的时间间隔是1/3的LeaseTime nextKeepAlive := time.Now().Add((time.Duration(karesp.TTL) * time.Second) / 3.0) ②定期去etcd server中get leader/MDS1，看是否还存在。这里涉及到定期get的时间 PeriodicGetTime，

UCX ●NVIDIA Mellanox 开源项目 ●支持RDMA，TCP，Shared memory等 ●能透明支持多个链路传输，例如多网卡bond ●编译成.so或lib的方式，可以集成到应用程序里 ●有完善的配置功能，ucx_info可以dump配置信息 ●有性能测试工具 ●比较详细的文档2223 UCS ●是一些工具代码，例如 –链表 –hash table –epoll socket代码不少地方需要文件句柄表示连接，使用句柄可以减少代码修改。例如 SocketOptions.fd为-1表示尚未连接。 ●UcpCm返回的文件句柄实际上是pipe的写端句柄 ●记得brpc的event dispatcher是边沿触发 ●写端句柄永远不会触发可读事件 ●写端句柄第一次epoll会返回可写，可写是brpc判断连接成功的措施 ●UcpCm从来不会写入pipe，如果pipe有可读字节，会打印错误，说明有地方遗漏了修 地方遗漏了修 改。 ●Socket通过关闭UcpCm返回的句柄来关闭连接。此举和Socket原来代码一样，减少了修 改。UcpCm检测到pipe读端可读，关闭UcpConnection。 ●以上修改实际上绕过了BRPC的Event dispatcher触发读写机制，UCX自己完成发送接收45 连接管理器UcpCm ●连接管理类 –全局唯一对象 –通过UcpCm * get_or_create_ucp_cm(void)获取