⼤数据计算场景 • 中间件数据存储场景 • ⽀持POSIX兼容的⽂件API • ⽀持低延迟的⽂件数据访问Curve⽂件系统⾯临的问题 • ⽤户态实现 • 稳定性/可靠性⾼ • 容易更新及维护 • 基于FUSE提供POSIX兼容⽂件接⼝ • 问题 • 相对kernel⽂件系统的实现(ext4, xfs)性能 差异⼤，延迟⾼FUSE⽂件IO读写流程 • 场景1 pytorch 基于FUSE的实现 • curve / ceph / gluster • LD_PRELOAD重载⽂件系统系统调⽤ • vpp / f-stack / DirectFUSE • Kernel版本实现 • BentoFS 基于rust的实现采⽤LD_Preload⽅式瓶颈分析 • 环境 • FUSE daemon使⽤ passthrough_ll 调⽤底层ext4 • 进程共享内存通信延迟10us+ 通过贡献代码、丰富⽂档、提交issue、改进⽹站、交流分享等，提⾼⾃⼰专业 能⼒的同时还可以提升个⼈影响⼒、扩展⼈脉。 • 项⽬https://github.com/opencurve/curve • 版本发布周期：每半年⼀个⼤版本，1～2个⽉⼀个⼩版本 • 了解Curve进展：每隔2周的Curve周会说明Curve进展以及讨论相关问题 • 提交bug与建议：http://github.com/opencurve/curve/issues

SnapshotRef & CloneRef：快照总体流程 • 1.用户发起快照，生成快照任务，并持久化到 etcd，开始执行快照任务。 • 2.在curve中创建内部快照，并返回快照信息， 然后将快照信息更新到etcd。此时，即返回用 户快照成功，可以进行读写。 • 3.向mds查询快照的元数据，转储快照元数据 块metaObject。 • 4.根据快照元数据信息，转储快照数据块 dataObject。 string 快照唯一Id user string 所属用户 fileName string 快照目标卷名 snapshotName string 快照名 seqNum uint64_t 快照版本号 chunkSize uint32_t chunk的size segmentSize uint64_t segment的size fileLength uint64_t 卷的大小 time 文件格式协议 版本号 demaged bool 损坏标记 sn uint64_t 快照版本号 bits uint32_t 位图的位数 bitmap char[] 位图 crc uint32_t 上述字段的crc 校验码 padding / 填0，以补足 4KBCHUNKSERVER端快照实现-写时复制原理  写时复制通常使用版本号实现  复制时仅复制元数据，并增加版本号  写

软件质量的定义是：软件与明确地和隐含地定义的需求相一致的程度。 为了确保最终交付的软件满足需求，必须将质量控制贯穿于设计、开发到测试的整个流程中。 设计  设计流程  文档规范 开发  编码规范与提交流程  版本管理 测试  测试方法论  CI与异常测试 6/33设计流程 Curve团队采用敏捷开发模式，负责人在制定迭代计划时，确认哪些任务需要设计 文档：  小需求（改动小）将实现思路记 程度上保证master分支的稳定性。 master 10/33版本管理 Curve版本命名规则是x.y.z{-后缀}  x为主版本号，每次发布大版本时递增； 大版本一般半年发布一次。  y为次版本号，每次发布小版本时递增; 小版本一般1~2个月发布一次。  z为修订号，修复一批bug后递增。  后缀表示版本状态，beta表示测试版本，rc 表示发布候选版本，空白表示正式版。 Curve所有功能 Curve所有功能开发均在master分支进行，而版本发布则在相应的release分支进行：  从master拉出一个新分支release-x.y，打beta版标签后，提交QA团队测试 ；  beta版的bug修复代码先合入master分支，再cherry-pick到release-x.y分支；  beta版bug修复完成后，打rc版标签（可能有多个rc版），上线到测试环境；  经bug修复和长时间

linux 2.6.39) #define O_TMPFILE 020000000|O_DIRECTORY #define O_NDELAY O_NONBLOCK(O_NDELAY是在System V的早期版本引入的，后改进为O_NONBLOCK) flags中必须access mode：O_RDONLY, O_WRONLY, O_RDWR其中之一；© XXX Page 4 of 23 文件创建标志只影响打开操作 e引起的文件属性的更新。 O_SYNC O_DSYNC: 每次write都等待物理I/O完成，但是如果写操作不影响读取刚写入的数据，则不等待文件属性更新（在linux 2.6.33之前只有O_SYNC flag， 但是在绝大多数文件系统中对O_SYNC的实现都是O_DSYNC的含义，在2.6.33版本支持了O_DSYNC flag，且值使用原O_SYNC的值，但为了兼容老版本的O_SYNC，现在 : 以目录形式打开，如果pathname不是一个目录则会打开失败。 O_DIRECTORY : 。 O_NOFOLLOW 如果pathname是一个符号链接，则会打开失败（ELOOP） : 不更新Inode中的last access time（进程uid=文件uid或者进程在它的user namespace有CAP_FOWNER, 而文件的uid在这个namespace中有一个映射）。 O_NOATIME

© XXX Page 1 of 9 Curve支持S3 数据缓存方案© XXX Page 2 of 9 版本 时间 修改者 修改内容 1.0 2021/8/18 胡遥 初稿 背景 整体设计 元数据采用2层索引 对象名设计 读写缓存分离 缓存层级 对外接口 后台刷数据线程 本地磁盘缓存 关键数据结构 详细设计 Write流程 Read流程 ReleaseCache流程 ReleaseCache流程 Flush流程 FsSync流程 后台流程 poc测试验证 背景 基于s3的daemon版本基于基本的性能测试发现性能非常差。具体数据如下： 通过日志初步分析有2点原因© XXX Page 3 of 9 1.append接口目前采用先从s3 get，在内存中合并完后再put的方式，对s3操作过多 2.对于4k 小io每次都要和s3交互，导致性能非常差。 因此需要通过Cache模块解决以上2个问题。 er的碎片整 理（马杰负责）模块进行truncate的无效数据清理 后台刷数据线程© XXX Page 4 of 9 启动后台线程，将写Cache定时刷到S3上，同时通过inodeManager更新inode缓存中的s3InfoList。具体细节见 本地磁盘缓存 如果有配置writeBack dev，则会调用diskStroage进行本地磁盘write，最终写到s3则由diskStroage模块决定。

4. 5. 6. 1. 2. 背景 只考虑单客户端, 单metaserver 为了解决的问题: 客户端在对一个文件的某个部分多次写入后, 同一个chunk会产生很多版本数据; 而客户端在读的时候, 会需要对这些chunk进行筛选和构建, 得到有效的部分, 越是散乱的状态, 就越需要发送更多次读请求至s3. 最后导致无效旧数据的堆积和读请求性能的下降, 所以需要在合适的时候进行重叠元数据和数据的合并 应用变更 - 先读写新增的s3 objects列表, 由于新增了version字段, 不会涉及到覆盖老的对象 - 加锁, 增量的更新inode的s3chunkinfolist, 保证原子更新, 更新失败回退新增数据 - 等待N秒, 保证mds已经告知client缓存失效, 需要更新为新的s3chunkinfolist // 需不需要这个步骤@xuchaojie @chenwei确认 - 删除老的object

+ 持久化文件 字段 字节数 说明 CURVEFS 7 magic number（常量字符 "CURVEFS"），用于标识该文件为 curvefs 元数据持久化文件 version 4 文件版本号（当文件格式变化时，可以 100% 向后兼容加载旧版持久化文件） size 8 键值对数量 key_value_pairs / 键值对（当 size 为 0 时，该字段为空） EOF 1 特殊标记常量 两个哈希表 (2) 在字典中维持一个索引计数器变量 rehashidx, 并将它的值设置为 0, 表示 rehash 工作正式开始 (3) 在 rehash 进行期间, 每次对字典执行添加、删除、查找或者更新操作时, 程序除了执行指定的操作以外, 还会顺带将 ht[0] 哈希表在 rehashidx 索引上的所有键值对 rehash 到 ht[1], 当 rehash 工作完成之后, 程序将 rehashidx 执行期间的哈希表操作： 因为在进行渐进式 rehash 的过程中, 字典会同时使用 ht[0] 和 ht[1] 两个哈希表, 所以在渐进式 rehash 进行期间, 字典的删除 (delete)、查找(find)、更新(update) 等操作会在两个哈希表上进行: 比如说，要在字典里面查找一个键的话，程序会先在 ht[0] 里面进行查找，如果没找到的话，就会继续到 ht[1] 里面进行查找，诸如此类 另外, 在渐进式

fuse_file_info *fi); 根据inode id 找到inode id 对应的inode 结构（从缓存或者metaserver） 根据to_set字段设置相应的attr字段，然后持久化到metaserver，并更新本地缓存。 access 可先不支持，返回ENOSYS rename void (*rename) (fuse_req_t req, fuse_ino_t parent, const char & fsync 缓存的问题暂时先不考虑太细，目前默认数据和元数据直接存储到底层，这两个也可先不实现 其他 xattr系列接口，chubaofs都没实现，目前先不考虑 fuse高版本新增的接口如lseek等，在低版本中没有，因此不是必须接口，也先不实现。 功能分析 根据上述接口的分析，可以把client端的功能进行汇总，client需实现的功能主要有： 缓存文件系统元数据（包括super

© XXX Page 1 of 19 curvefs copyset与fs对应关系© XXX Page 2 of 19 版本 时间 修改者 修改内容 1.0 2021/7/23 陈威 初稿 1.1 2021/8/4 陈威 根据评审意见修改 1.2 2021/8/9 陈威 增加详细设计 1、背景 2、chubaofs的元数据管理 2.1、meta partition的创建 2.2、meta client端缓存所有open的inode，读写的时候，根据inode的元数据，去对应的volume或者S3进行读写。如果涉及到inode的修改，根据inodeId查询对应的copyset，去对应的copyset进行inode的更新。 bool :: ( , , :: < > ) CopysetManager GenCopyset const ClusterInfo& cluster int mds 15d metaserver 10d 考虑到partition和copyset的多对一关系会带来开发商的复杂性，是否考虑先只实现partition和copyset一对一的情况。等下一个版本，再实现的多对一的场景。 接口设计：https://github.com/opencurve/curve/pull/495 增加copyset.proto 增加heartbeat.proto

到 4.2.2 2 支持 Debian9 、 Debian10 、 Debian11 3 支持 gcc clang 更新内容 Curve1 编译 Debian11-Dockerfile .bazelrc bazel 版本： 4.2.2 （ bazelisk) docker run -v $(pwd):/curve -it opencurvedocker/cur