软件质量的定义是：软件与明确地和隐含地定义的需求相一致的程度。 为了确保最终交付的软件满足需求，必须将质量控制贯穿于设计、开发到测试的整个流程中。 设计  设计流程  文档规范 开发  编码规范与提交流程  版本管理 测试  测试方法论  CI与异常测试 6/33设计流程 Curve团队采用敏捷开发模式，负责人在制定迭代计划时，确认哪些任务需要设计 文档：  小需求（改动小）将实 小需求 实现思路 开发 大需求 设计文档 POC 开发 7/33设计文档规范 设计文档需要具备以下内容：  修订记录  审批记录  系统介绍  相关调研  架构  重要流程  关键算法  接口  数据库设计  非功能特性设计  参考文献 8/33代码编写规范 Curve代码编写规范遵循Google Style Guides（https://google Dailybuild测试 提交issue 开发设计 提交PR review +1 CI测试（编译、静态检 查、单元测试、集成测 试、覆盖率80%卡点） 合入master 分支 代码提交流程 异常自动化 测试 混沌测试 （每周一次） CI测试（编译、静态检 查、单元测试、集成测 试、覆盖率80%卡点） 邮件通知 Curve所有代码均在github托管。新 代码需要通过CI测试和code

一个对象作为 EC 组的一个满条带 挖洞即时空间回收拓扑 • 管理和组织机器 • 软件单元：chunkserver • 物理机：server • 故障域：zone • 物理池：poolIO流程 client MDS leader Chunk server 1、发起请求 2、查询元数据 5、返回结果 5、返回结果 user 3、查询leader节点 4、向leader cs发起请求 • 集群状态查询工具 • curve_ops_tool • 自动化部署工具 • 一键部署，一键升级高质量 • 良好的模块化和抽象设计 • 完善的测试体系 • 单元测试 行覆盖80%+，分支覆盖70%+ • 集成测试 Given When Then 方法 完备的测试用例集 • 自动化异常测试 41个异常用例 • 自动化大压力随机故障注入 20轮随机故障注入背景 01 02 03

2021-05-20 胡遥 初稿 2021-07-20 胡遥 细化write和read流程 整体架构 整体思路 接口和关键数据结构 mds.proto client端数据结构 metaserver.proto space相关数据结构和proto 关键流程 init流程 write流程 read流程 整体架构 S3ClientAdaptor模块：负责将文件数据进行chunk，以及bl Page 3 of 11 整体思路 curvefs对接s3和对接volume主要的区别在于数据持久化和空间分配部分，而元数据的操作尽量保持统一。因此我们涉及到修改client的流程主要在read/write/flush，以及空间分配申请（s3不需要释放空间，可 直接删除对应s3 object） 文件首先会按照chunk进行拆分，每个chunk固定64M/1G（ private: std::atomic chunkId_;© XXX Page 10 of 11 }; 关键流程 关键流程包括S3ClientAdaptor的init，write，read，delete和后台元数据整理以及数据回收流程 init流程 1.将conf中blockSize，chunkSize，metaServer和allocateServer ip保存在S3ClientAdaptor中

背景 整体设计 元数据采用2层索引 对象名设计 读写缓存分离 缓存层级 对外接口 后台刷数据线程 本地磁盘缓存 关键数据结构 详细设计 Write流程 Read流程 ReleaseCache流程 Flush流程 FsSync流程 后台流程 poc测试验证 背景 基于s3的daemon版本基于基本的性能测试发现性能非常差。具体数据如下： 通过日志初步分析有2点原因© XXX Page dex找到chunk，然后通过offset~len找到是否有合适的datacache或者new datacache。 对外接口 流程上对于读写缓存有影响的接口包括：write，read，releaseCache，flush，fssync。后面会详细介绍这些接口流程。这里不需要提供truncate接口，可以由client直接修改inode的len，由metaserver的碎片整 理（马杰负责）模块进行truncate的无效数据清理 chunkId; uint32_t chunkPos_;© XXX Page 8 of 9 uint32_t len_; char* data_; }; 详细设计 Write流程 1.加锁，根据inode和fsid找到对应的fileCacheManager，如果没有则生成新的fileCacheManager，解锁，调用fileCacheManager的Write函数。 2

clientV3的concurrency模块构成 3.2 Campaign的流程 3.2.1 代码流程说明 3.2.2 举例说明Campagin流程 3.3 Observe的流程 4. MDS使用election模块的功能进行选主 4.1 Curve中MDS的选举过程 4.2 图示说明选举流程 4.2.1 正常流程 4.2.2 异常情况1：MDS1退出，可以正常处理 4.2.3 异常情况 30 1. 2. Campagin用于leader竞选 Observe用于监测集群中leader的变化 3.2 Campaign的流程 3.2.1 代码流程说明 如对相关代码实现不感兴趣，请直接跳到 3.2.2 举例说明Campagin流程 按照官方对Campagin的定义： blocked until it becomes the leader func (e *Election) leaderSession = nil } return err } e.hdr = resp.Header© XXX Page 7 of 30 return nil } 代码流程说明如下：© XXX Page 8 of 30© XXX Page 9 of 30© XXX Page 10 of 30 etcd中的revision是全局的，只要有key-value的修改(put

copyset个数是否可以动态调整？ 4、curvefs的topo信息 5、curvefs mds和metaserver的心跳 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的内存估算 对应的copyset上插入一条rootinode的记录。最后修改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、检查挂载点是否已经存在 就为这个fs创 建一个新的copyset。© XXX Page 12 of 19© XXX Page 13 of 19 6.4、open流程© XXX Page 14 of 19© XXX Page 15 of 19 6.5、读写流程 读写流程和之前的读写流程大致保持不变。变化点在于之前inode修改是直接去metaserver上修改，现在变成了去copyset上修改。 client端缓存所

稳定性/可靠性⾼ • 容易更新及维护 • 基于FUSE提供POSIX兼容⽂件接⼝ • 问题 • 相对kernel⽂件系统的实现(ext4, xfs)性能 差异⼤，延迟⾼FUSE⽂件IO读写流程 • 场景1 pytorch example word_language_model • LOOKUP inode 返回 fstat + timeout设置 • OPEN 打开 inode返回ok 写⼊内容从0～16KB不等 • SETATTR inode 根据UID，ATIME，CTIME，length来设置属性 • 关闭⽂件时会发送FLUSH请求和RELEASE请求FUSE⽂件IO读写流程FUSE的IO路径及瓶颈分析 • 对⽐测试 • ⽂件访问测试直接访问ext4 • 通过FUSE访问passthrough_ll底层ext4 • 内核调⽤延迟测试 • 与FUSE Daemon通讯120us左右，FUSE • fuse_ll_ops开销10us-基于FUSE的优化框架 • 框架优化的要点 • 共享inode cache • 共享data cache的映射 • GETATTR流程 • ⽂件读取流程 • 相关⼯作 • extFUSE • google android12 passthrough什么是eBPF • ebpf是不同环境下内核配置， 调试，监控⼯具 • map映射

ChunkServer：通过raft维护复制组内的主-从关系CLIENT IO流程 用户下发一个写请求 off: 8M len: 16M 请求落在两个逻辑chunk上，所以 请求会被拆分成两个子请求：  ChunkIdx 1, off: 8M len 8M  ChunkIdx 2, off: 0 len 8MCLIENT IO流程 子请求由哪个chunkserver处理，依赖以 下信息： 复制组所在的chunkserver列表  复制组的leader信息CLIENT IO流程 逻辑chunk与物理chunk映射关系 物理chunk所属的复制组(copyset)  由MDS分配并持久化，client拆分用户请 求时会获取并进行缓存  为了减少元数据量，MDS一次会连续分配 1G范围内的映射关系，称为SegmentCLIENT IO流程 复制组所在的chunkserver列表  chunkserver心跳定期上报给MDS 通过MDSClient向MDS获取 复制组的leader信息  复制组之间通过raft维护  通过CliClient向Chunkserver获取 这两种信息client也会进行缓存 上报心跳CLIENT IO流程 子请求处理步骤： 1. 从MDS获取逻辑chunk与物理chunk的 对应关系（包含逻辑池以及复制组信息） 2. 从MDS获取复制组所在的机器列表 3. 从Chunkserver获取复制组leader信息

CurveClient封装了Client接口，负责与MDS和ChunkServer交互。 CurveClient: • 负责管理快照和克隆源卷的引用计数。 SnapshotRef & CloneRef：快照总体流程 • 1.用户发起快照，生成快照任务，并持久化到 etcd，开始执行快照任务。 • 2.在curve中创建内部快照，并返回快照信息， 然后将快照信息更新到etcd。此时，即返回用 户快照成功，可以进行读写。 • 4.根据快照元数据信息，转储快照数据块 dataObject。 • 5.调用mds接口，移除curve内部的快照。 • 6.mds调用chunkserver接口，删除内部快照 数据 快照流程： chunk chunk chunk chunkserver meta object data object data object S3 Snap Task etcd mds file产生，直接读取chunk file b) 打快照后写过，触发了cow， 有snap file， 合并读取 c) 卷从未写过， 两者都没有，返回NOTEXIST 转储内部快照，即读内部快照的三种情况：克隆总体流程 • 1. 用户发起克隆，生成克隆任务，并持 久化任务元数据到etcd，开始执行克隆 任务。 • 2. 调用mds接口创建clone卷信息，该 clone卷是个临时卷，位于/clone目录下。

完成raft成员之间的选举，日志复制， 安装快照等操作。 ChunkServer架构CopysetNode封装了braft的Node，并 实现了braft的状态机，完成与raft的交 互。详细交互流程后面展开。 CopysetNodeManager负责管理 CopysetNode的创建、初始化、删除等 ChunkServer架构心跳模块有两方面的职责： 1、向MDS节点上报心跳，心跳中包括 entry成功，并且有一个peer也落 盘成功，则commit 5. Commit后apply，此时把写请求写到chunkChunkServer核心模块-CopysetNode 坏盘（CS1对应的盘）后的迁移流程 初始状态，copyset1，copyset2，copyset3的三个副本分别在 CS1,CS3,CS4上，完成迁移后，CS1上的副本迁移到CS2上 ① CS1超时未向MDS上报心跳（默认半小时） ⑧ MDS在得知CS1上的所有copyset都成功迁移后，把CS1设置为 retired，CS1下线完毕。ChunkServer核心模块-CopysetNode 换盘（CS1对应的盘）后重新上线的流程 初始状态，copyset1，copyset2，copyset3的三个副本分别在 CS2,CS3,CS4上，完成恢复后，CS2上的copyset1,2,3迁移到CS1上 ① CS1换了新盘，并重新格式化后启动chunkserver