小版本一般1~2个月发布一次。  z为修订号，修复一批bug后递增。  后缀表示版本状态，beta表示测试版本，rc 表示发布候选版本，空白表示正式版。 Curve所有功能开发均在master分支进行，而版本发布则在相应的release分支进行：  从master拉出一个新分支release-x.y，打beta版标签后，提交QA团队测试 ；  beta版的bug修复代码先合入master分支，再c beta版bug修复完成后，打rc版标签（可能有多个rc版），上线到测试环境；  经bug修复和长时间运行测试后，若代码达到正式上线标准，则发布正式版。 v1.0.0-beta v1.1.0-beta master v1.1.0-rc0 release-1.1 v1.0.0-rc0 v1.0.0 v1.0.1 release-1.0 v1.0.0-rc1 新功能 Bug修复 cherry-pick 单元测试的完备程度，如下图所示： 13/33集成测试 测试目的 测试内容 单元测试后，有必要进行集成测试，发现 并排除在模块连接中可能发生的上述问题， 最终构成要求的软件子系统或系统。集成 测试需要关注的主要是各模块连接起来后 的问题：  穿越模块接口的数据是否会丢失；  子功能的组合是否可以达到预期的要求；  子模块之间是否会相互影响；  单个模块的误差积累是否会放大，从而

Trash机制： Session机制： 遗留问题 工作量评估 背景 目前curvefs client版本对删除unlink和rmdir的设计只有简单的删除inode和dentry结构，遗留了nlink和lookup count相关的内容还未实现，是不完备的。本文首先调研moosefs，chubaofs等分布式系统，参考并设计解决上述遗留问题。 当前删除接口代码如下：© XXX Page << ", inode = " << dentry.inodeid(); return ret; } return ret; } 存在两个问题: 一是删除时nlink字段未考虑： 文件的nlink用于实现hard link。 hard link使用nlink字段表示文件的link的引用计数，第一次创建文件是nlink字段为1。每创建一个新的指向该文件的hard XXX Page 8 of 15 1. 2. 1. 2. 1. 1. 2. 3. 4. 5. 缺点： moosefs是单mds，所以不存在接口原子性的问题，这块要重新考虑，我们实现上会比moosefs复杂，需要引入一些额外的复杂性。 由于是按目录管理trash，那么必须是两个trash（其中一个是reserve）以区分两种不同的情况。 chubaofs

通过iSCSI支持更多系统，例如Windows, 类UNIX系统等，使用两项基础 技术 • TCP/IP • SCSI • 替代SAN • 可靠性、稳定性方面有自己的的特色，使用raft副本一致性和copyset概念可以自动 修复损坏的副本，并且可扩容。无论在可靠性、稳定性还是性价比方面都很有优势， 使用廉价硬件搭建。iSCSI软件 • Client端: iscsi initiator，系统自带 • Linux open-iscsi cache: enabled, doesn't support DPO or FUA • 这个对于curve驱动，Linux Initiator的dmesg不会显示这个信息TGT的性能问题 • 性能问题主要体现在不能有效使用多CPU • 对多个socket connection，在单线程里做event loop多路复用。 • 多个target时，如果挂的设备多，一旦客户端请求量大，就会忙不过来。 样多个卷共享一个target， 限制使用一个CPU。 • 管理平面不变。主线程里的事件循环及问题： 管理面是主线程，登录，增、删、改target,lun,session,connection,params 都在主线程，而target epoll 线程也要使用这些数据，多线程冲突，数据一 致性问题就来了对TGT的性能优化（续) • 为每一个target增加一把锁 • Target event

点初始状态一致的时候，保证节点之间状态一致。 raft日志复制RAFT协议简介 raft配置变更 • 配置：加入一致性算法的服务器集合。 • 集群的配置不可避免会发生变更，比如替换宕机的机器。 直接配置变更可能出现双主问题 • 共同一致（joint consensus） • 集群先切换到一个过渡的配置(old + new)，一旦共同一 致已经被提交，系统切换到新的配置(new)。RAFT协议简介 日志压缩 • mds发起配置变更，copyset复制组执行 • 在curve自动容错和负载均衡时，需要进行raft配 置变更。 • 自动容错保证常见异常（如坏盘、机器宕机）导 致的数据丢失不依赖人工处理，可以自动修复。 • 负载均衡和资源均衡保证集群中的磁盘、cpu、内 存等资源的利用率最大化。 Curve块存储和文件存储的配置变更实现基本一致CURVE的RAFT配置变更 异常场景下配置变更 • ReplicaSchedule raft在Curve中的应用 05 Q&A 04 Curve对raft的优化Curve对RAFT的优化 优化点一：轻量级快照 问题背景： raft的快照需要定期打快照，用来清理log。对于Curve块存储场景，系统状态就是Chunk当前的数据。 如果把所有chunk 拷贝一遍打快照，会出现两个问题： 1. 每次快照，空间上要多出1倍，空间浪费严重。 2. Curve块存储快照间隔默认30 分钟一次，每次快照

打印一条error日志。调度模块感知到offline状态， 触发chunk server的recover修复。 心跳正常 心跳正常 超过miss时间 未超过offline时间 UNSTABLE ONLINE OFFLINESCHEDULE Schedule（系统调度）是为了实现系统的自动容错和负载均衡，这两个功能是分布式 存储系统的核心问题，也是 curve 是否能上生产环境的决定因素之一。 • 自动容错保证常 自动容错保证常见异常（如坏盘、机器宕机）导致的数据丢失不依赖人工处理，可 以自动修复。 • 负载均衡和资源均衡保证集群中的磁盘、cpu、内存等资源的利用率最大化。SCHEDULE Schdedule的具体实现 Coordinator: 调度模块的对外接口。心跳会将 chunkserver上报上来的copyset信息提交给 Coordinator，内部根据该信息判断当前copyset是否 有配置变更任务执行，如果有任务则下发。

et上，有一个可以由多少fs共用的限制。这个限制通过配置文件进行配置。用户挂载时可以通过参数配置是否独占copyset。原因是，为了避免fs独占copyset 带来的copyset数量过多影响性能的问题。 3.3 copyset个数是否可以动态调整？ 根据copyset个数是否可以动态调整，有两种实现。 一种是curve块存储方案，在集群初始化的时候，把所有的copyset创建好。采用这种方式， 文件和目录，会导致copyset管理的元数据越来越多；如果copyset管理的Inode分配完了，转为readonly状态，随着文件和目录的删除，copyset管理的元数据会越来越少。类chubaofs方案的均衡问题如何解决? CopySetScheduler: copyset均衡调度器。根据集群中copyset的分布情况生成copyset迁移任务； LeaderScheduler: leader均衡调度器。 yset信息。 7.2 mds端 1、需要实现topo模块 2、实现mds和metaserver的心跳 3、实现fs和copyset的分片策略的实现 4、实现出现异常场景下的数据恢复，副本修复的调度。 7.3 metaserver端 1、需要提供copyset的创建功能 2、由copyset负责inode和dentry的管理 3、定期向mds上报心跳，并根据心跳结果执行配置变更

| 分布式存储的分类 | 分布式存储的要素 02 03 04 Ceph 架构简介 | 场景介绍 | 使用中的问题 Curve 架构简介 | 数据对比 | 应用情况 FAQ 答疑存储的发展 互联网时代，数据大爆炸 大型主机 成本高 单点问题 扩容困难 各存储设备通过网络互联 大规模 弹性扩容 底层构建在分布式存储之上 云的概念 成本：共用基础设施 弹性：随意扩缩容 client W W W client分布式存储介绍 01 存储的发展 | 分布式存储的分类 | 分布式存储的要素 02 03 04 Ceph 架构简介 | 块存储场景 | 使用中的问题 Curve 架构简介 | 数据对比 | 应用情况 FAQ 答疑架构简介 — 总体架构 开源分布式存储界的扛把子 支持块存储、文件存储、对象存储架构简介 — 概念介绍 object：存储单元 -> 文件系统 -> 块设备层 -> 不同协议/驱动使用中的问题 • io抖动（一致性协议）： 异常场景（比如阵列卡一致性巡检，坏盘，慢盘，网络异常），服务升级 • 性能差（一致性协议）：在通用硬件下，无法支撑数据库、kafka等中间件对存储性能和稳定性要求 • 容量不均衡（数据放置）：集群各节点容量不均衡需要人为干预 • 上述问题和架构涉及、核心功能的选型有关，在已有开源版本上改进代价很大分布式存储介绍

采⽤eBPF加速云原⽣环境中 Curve⽂件系统性能 ⽹易数帆科技 向东提纲 • 什么是Curve • Curve的应⽤场景及挑战 • Curve客户端⾯临问题及分析 • 什么是ebpf • 基于epbf的Curve Cache设计 • Curve社区介绍Curve是什么？ • Curve云原⽣软件定义存储 • Curve分布式块存储 • Curve分布式⽂件存储 ⼤数据计算场景 • 中间件数据存储场景 • ⽀持POSIX兼容的⽂件API • ⽀持低延迟的⽂件数据访问Curve⽂件系统⾯临的问题 • ⽤户态实现 • 稳定性/可靠性⾼ • 容易更新及维护 • 基于FUSE提供POSIX兼容⽂件接⼝ • 问题 • 相对kernel⽂件系统的实现(ext4, xfs)性能 差异⼤，延迟⾼FUSE⽂件IO读写流程 • 场景1 pytorch 瓶颈在/dev/fuse通讯开销基于FUSE可能的优化点 • 降低内核与libfuse通讯延迟 • 基于⽂件属性的操作内核直接返回？ • 基于⽂件数据的操作先内核读写 cache？实现POSIX兼容API途径及问题 • 基于FUSE的实现 • curve / ceph / gluster • LD_PRELOAD重载⽂件系统系统调⽤ • vpp / f-stack / DirectFUSE •

e结构（包括file length）; inode修改需要持久化到底层并修改本地cache； 调用curve client接口，写curve卷对应[offset，len] 数据。 （这里涉及到一个问题，是否从fuse下来的请求是4k对齐的，如果不是，那么这里还需要修改为read merge write，即读出未对齐缺少的部分，然后整个[offset,len] 调用curve client写）; 根据inode结构，拆分unwritten/未分配的区域与写过的区域，未写过的区域填0，其他区域继续读取 根据inode结构中信息，调用curve client接口，读取对应的[offset, len]数据。（这里同样要考虑4k对齐的问题，如果不对齐，则需要读取对齐的区域，然后去掉多读的部分）（读写可以做数据缓存， 当前先不考虑）。 open void (*open) (fuse_req_t req, fuse_ino_t ino ino, uint64_t nlookup); 根据inodeid找到对应的inode结构，lookup count值减少nlookup。 （ ） 这里涉及到一个lookup count 存在哪里的问题 unlink void (*unlink) (fuse_req_t req, fuse_ino_t parent, const char *name); 根据parent inode id 和

rename：rename /A/C到/B/E symbolic link： hardlink：生成一个hardlink /B/E，指向文件/A/C list：遍历/A目录 5.1.2 好处 5.1.2 问题 5.2 分片方式二：Inode按照inodeid进行分片，Dentry按照parentid进行分片 rename：rename /A/C到/B/E hardlink：生成一个hardlink /B/E，指向文件/A/C link, symlink，rename的处理。 fastcfs的inode和dentry没有分开，两者在同一个结构体里面。这种方式如何应对硬链接？ 看了下fastcfs的实现，在硬链接这里是有问题的。 考虑inode和dentry的内存组织形式，可以考虑hashmap，skiplist，btree等，但是无论选择哪种方式组织，节点都可以抽象成一个Key - Value的形式。 inode可以抽象成 me查询inodeid，第二步通过inodeid查询inode结构体在同一个分片上处理。查询时，client只 需要向metaserver发送一次请求，就可以完成上面两步的查询任务。 5.1.2 问题 在一种特殊的情况下，可能出现无法按照的parentid找到对应inode的情况。 还是是上面的文件系统，生成一个hard link，/B/E指向/A/C 元数据© XXX Page 17 of