基于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

chunkid 持久化© XXX Page 2 of 3 1. 2. 3. 1. 2. 3. 4. 5. 6. 1. 2. 3. 4. 1. 1. 1. 2. 1. 2. 3. 4. 3. 2. 背景 将原有的获取chunkid的方法从space迁入mds中，并持久化写入etcd中； 只考虑单 ChunkIDGenerator 类对象，方法 AllocateS3Chunk 调用 ChunkIDGenerator对象的GenChunkID方法； ChunkIDGenerator 类 构造函数 初始化 init 函数：用于初始化或者更改 ChunkIdAllocatorImpl 的一些配置。但是这些配置不会立即生效，而是等到当前 chunkId池枯竭时才会生效。 析构函数 GenChunkID 申请的chunkID池是否枯竭？

© XXX Page 1 of 12 元数据持久化© XXX Page 2 of 12 前言 Raft Log Raft Snapshot 持久化文件 key_value_pairs 其他说明 实现 1、inode、entry 的编码 2、KVStore Q&A 单靠 redis 的 AOF 机制能否保证数据不丢失? redis 的高可用、高可扩方案？ redis + muliraft redis 中哈希表实现的优点？ 参考 前言 根据之前讨论的结果，元数据节点的架构如下图所示，这里涉及到两部分需要持久化/编码的内容： Raft Log：记录 operator log Raft Snapshot：将内存中的数据结构以特定格式 dump 到文件进行持久化© XXX Page 3 of 12 Raft Log +------+------------+-----+----- -----+----------------+---------+ 持久化文件 字段 字节数 说明 CURVEFS 7 magic number（常量字符 "CURVEFS"），用于标识该文件为 curvefs 元数据持久化文件 version 4 文件版本号（当文件格式变化时，可以 100% 向后兼容加载旧版持久化文件） size 8 键值对数量 key_value_pairs / 键值对（当

判断inode结构中，对应请求[off, size]位置的空间是否有分配：如果未分配或只有部分分配空间，则调用空间分配器分配空间，并根据空间分配器返回结果，修改inode结构（包括file length）; inode修改需要持久化到底层并修改本地cache； 调用curve client接口，写curve卷对应[offset，len] 数据。 （这里涉及到一个问题，是否从fuse下来的请求是4k对齐的，如果不是，那么这里还需要修改为read offset,len] 调用curve client写）; 修改inode结构，如果上述区域存在先前未写过的区域，则需要去掉unwritten，具体方式根据inode结构而定；inode修改需要持久化到底层并修改本地cache；© XXX Page 6 of 11 read void (*read) (fuse_req_t req, fuse_ino_t ino, size_t size, off_t 存， 当前先不考虑）。 open void (*open) (fuse_req_t req, fuse_ino_t ino, struct fuse_file_info *fi); posix语义中open支持的oflag主要有： O_RDONLY 只读打开 O_WRONLY 只写打开 O_RDWR 读写打开 以上3个必须指定且只能指定一个 O_APPEND 只追加写 O_CREAT 文件不存在时创建

是否需要做session机制（在metaserver打开），来维护inode的打开情况？ 方案设计 Trash机制： Session机制： 遗留问题 工作量评估 背景 目前curvefs client版本对删除unlink和rmdir的设计只有简单的删除inode和dentry结构，遗留了nlink和lookup count相关的内容还未实现，是不完备的。本文首先调研moosefs，chubaofs 指的是文件的访问计数。当文件/目录被打开时， ，该文件/目录仍然可以被打开的进程访问，不会造成崩溃或报错，我们的curvefs也需要实现 即使文件/目录已经被另一个进程删除了（nlink==0） 这样的语义。 这部分内容在fuse的相关接口中也有描述如下： /** * Forget about an inode * * This function is called when the moosefs 未对接forget moosefs 实现了在mds上open，因此删除时可以判断文件是否被打开 moosefs使用了两种机制，来实现上述功能，分别是trash机制和reserve机制（最新版本叫sustained），两种机制如下： trash机制： 对于所有TYPE_FILE类型的文件在删除时， ，则不会立即将该文件彻底删除，而是将其类型修改为TYPE_TRASH并且将该节点从文件树

运维——保障Curve始终稳定高效运行。 质量 ✓ 质量管理体系（设计、开发、review、CI） ✓ 测试方法论（单元测试、集成测试、系统测试） 监控 ✓ 监控架构 ✓ 指标采集、后端处理、可视化展示 运维 ✓ 运维特性 （易部署、易升级、自治） ✓ 运维工具（部署工具、管理工具） 4/33背景 01 02 03 04 Curve质量控制 Curve监控体系 Curve运维体系软件质量 软件质量的定义是：软件与明确地和隐含地定义的需求相一致的程度。 为了确保最终交付的软件满足需求，必须将质量控制贯穿于设计、开发到测试的整个流程中。 设计  设计流程  文档规范 开发  编码规范与提交流程  版本管理 测试  测试方法论  CI与异常测试 6/33设计流程 Curve团队采用敏捷开发模式，负责人在制定迭代计划时，确认哪些任务需要设计 文档：  小需求（改动小）将实现思路记 异常自动化 测试 混沌测试 （每周一次） CI测试（编译、静态检 查、单元测试、集成测 试、覆盖率80%卡点） 邮件通知 Curve所有代码均在github托管。新 代码需要通过CI测试和code review才 能合入master分支，确保新合入代码 的功能、正确性、规范性等都有基本 保障；而每日运行的dailybuild测试在 CI测试基础上增加了异常自动化测试 和混沌测试，确保master分支代码的

github代码仓库： https://github.com/opencurve/curveCURVE基本架构 01 02 03 04 ChunkServer架构 ChunkServer核心模块 新版本ChunkServer性能优化CURVE基本架构 • 元数据节点 MDS • 管理和存储元数据信息 • 感知集群状态，合理调度 • 数据节点 Chunkserver • 数据存储 • 副本一致性，raft Client • 对元数据增删改查 • 对数据增删改查 • 快照克隆服务器CURVE基本架构 01 02 03 04 ChunkServer架构 ChunkServer核心模块 新版本ChunkServer性能优化Curve ChunkServer是数据节点， 对外提供数据读写和节点管理功 能，底层基于ext4文件系统，操 作实际的磁盘。 ChunkServer架构Chu de封装了braft的Node，并 实现了braft的状态机，完成与raft的交 互。详细交互流程后面展开。 CopysetNodeManager负责管理 CopysetNode的创建、初始化、删除等 ChunkServer架构心跳模块有两方面的职责： 1、向MDS节点上报心跳，心跳中包括 ChunkServer本身的一些统计信息 2、解析MDS的心跳response中的raft

块设备服务，CurveFS会基于此实现。第一阶段的目标是实现 满足数据库场景的文件接口。 调研 开源fs 当前对已有的开源分布式文件系统进行了调研，主要包括系统架构，元数据内存结构，元数据持久化，调研文档如下： chubaofs: ChubaoFS© XXX Page 3 of 14 1. 2. 3. moosefs: https://kms.netease.com/ 要怎样的元数据节点的性能？ 可行性分析 方案对比 根据上述调研和测试结果，我们考虑了三种curvefs的元数据设计方案： CurveFS kv方案设计 curve实现块设备时，元数据不是扁平化的设计，而是采用来有目录层级的 namespace 方式，namespace 已经实现了 fs 元数据管理的雏形，具备了基本的元数据管理功能。（当时为什么要设计为 namespace 的管理形式？留有租户这个概念），直接基于 依赖于第三方kv存储，目前是etcd CurveFS 单机内存元数据设计 类似 fastcfs 和 moosefs 的元数据设计方式，采用通用的 dentry，inode 两层映射关系，所有的元数据都缓存在内存中，持久化在 binlog 文件中，binlog采用定期dump的方式删除。基于这种方式的开发： a. 性能 加载：数据量较大的情况下，元数据节点启动较慢；但是元数据使用 master-slave 可以降低

kServer交互。 CurveClient: • 负责管理快照和克隆源卷的引用计数。 SnapshotRef & CloneRef：快照总体流程 • 1.用户发起快照，生成快照任务，并持久化到 etcd，开始执行快照任务。 • 2.在curve中创建内部快照，并返回快照信息， 然后将快照信息更新到etcd。此时，即返回用 户快照成功，可以进行读写。 • 3.向mds查询快照的元数据，转储快照元数据 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端快照实现-写时复制原理  写时复制通常使用版本号实现  复制时仅复制元数据，并增加版本号  写

© 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 partition和data partition。meta partition管理的元数据，data partition管理数据。meta partition管理inode和dentry信息。 创建一个文件系统时，如何初始化meta partition？ master\cluster.go， chubaofs的文件系统使用volume的来表示，在创建一个文件系统的时候，会创建3个meta partition和10个data set 带来的copyset数量过多影响性能的问题。 3.3 copyset个数是否可以动态调整？ 根据copyset个数是否可以动态调整，有两种实现。 一种是curve块存储方案，在集群初始化的时候，把所有的copyset创建好。采用这种方式， 可以采用hash的方式去确定inode的分片。比如说， ， copysetid = (fsid + inodeid << shift ) % totalCopysetNum