背景 整体设计 元数据采用2层索引 对象名设计 读写缓存分离 缓存层级 对外接口 后台刷数据线程 本地磁盘缓存 关键数据结构 详细设计 Write流程 Read流程 ReleaseCache流程 Flush流程 FsSync流程 后台流程 poc测试验证 背景 基于s3的daemon版本基于基本的性能测试发现性能非常差。具体数据如下： 通过日志初步分析有2点原因© XXX Page 3操作过多 2.对于4k 小io每次都要和s3交互，导致性能非常差。 因此需要通过Cache模块解决以上2个问题。 整体设计 整个dataCache的设计思路，在写场景下能将数据尽可能的合并后flush到s3上，在读场景上，能够预读1个block大小，减少顺序读对于底层s3的访问频次。从这个思路上该缓存方案主要针对的场景是顺序写和顺序 读，而对于随机写和随机读来说也会有一定性能提升，但效果可能不会太好。 +inodeId。增加inodeId的目的是为了后续从对象存储上遍历，反查文件，这里就要求inodeId是永远不可重复。 读写缓存分离 读写缓存的设计采用的是读写缓存分离的方案。 写缓存一旦flush即释放，读缓存采用可设置的策略进行淘汰（默认LRU），对于小io进行block级别的预读。 即读写缓存相互没影响不相关， 缓存层级 缓存层级分为fs->file->chunk->datacache

差异⼤，延迟⾼FUSE⽂件IO读写流程 • 场景1 pytorch example word_language_model • LOOKUP inode 返回 fstat + timeout设置 • OPEN 打开 inode返回ok • GETATTR 返回fstat • READ inode 读取的内容不等从16KB到128KB • 关闭⽂件时会发送FLUSH请求和RELEASE请求 timeout设置 • WRITE 写⼊内容从0～16KB不等 • SETATTR inode 根据UID，ATIME，CTIME，length来设置属性 • 关闭⽂件时会发送FLUSH请求和RELEASE请求FUSE⽂件IO读写流程FUSE的IO路径及瓶颈分析 • 对⽐测试 • ⽂件访问测试直接访问ext4 • 通过FUSE访问passthrough_ll底层ext4 • 内核调⽤延迟测试 • fuse_ll_ops开销10us-基于FUSE的优化框架 • 框架优化的要点 • 共享inode cache • 共享data cache的映射 • GETATTR流程 • ⽂件读取流程 • 相关⼯作 • extFUSE • google android12 passthrough什么是eBPF • ebpf是不同环境下内核配置， 调试，监控⼯具 • map映射

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

Curve文件系统空间分配方案（基于块的方案，已实现）© XXX Page 2 of 11 背景 本地文件系统空间分配相关特性 局部性 延迟分配/Allocate-on-flush Inline file/data 空间分配 整体设计 空间分配流程 特殊情况 空间回收 小文件处理 并发问题 文件系统扩容 接口设计 RPC接口 空间分配器接口 背景 根据 ，文件系统基于当前的块进行实现，所以需要 分） 本地文件系统空间分配相关特性 局部性 尽量分配连续的磁盘空间，存储文件的数据。这一特性主要是针对HDD进行的优化，降低磁盘寻道时间。 延迟分配/Allocate-on-flush 在sync/flush之前，尽可能多的积累更多的文件数据块才进行空间分配，一方面可以提高局部性，另一方面可以降低磁盘碎片。 Inline file/data 几百字节的小文件不单独分配磁盘空间，直接把数据存放到文件的元数据中。 ree对所有的free extent进行管理）。 当前设计不考虑持久化问题，空间分配器只作为内存结构，负责空间的分配与回收。在初始化时，扫描文件系统所有inode中已使用的空间。 空间分配流程 在新文件进行空间分配时，随机选择level1中标记为0的块，先预分配给这个文件，但是并不表示这个块被该文件独占。© XXX Page 4 of 11 1. 2. 3. 以下图为

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

软件质量的定义是：软件与明确地和隐含地定义的需求相一致的程度。 为了确保最终交付的软件满足需求，必须将质量控制贯穿于设计、开发到测试的整个流程中。 设计  设计流程  文档规范 开发  编码规范与提交流程  版本管理 测试  测试方法论  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

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端缓存所

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