event loop – memory register cache –config file24 UCT ●特点是比较原始，开销小，但是没有很强的功能 ●是网络接口层，主要功能是网卡发现和远程内存传输支持，提供component查询和 memory domain的打开 ●一个component包含若干 memory domain resource,一个memory domain又可以包含若干个 –Active message, atomic operation, tag match, stream27 典型的RDMA栈28 UCX 编程的一些基本概念 ●Context –收集机器资源（内存，网卡等)，在应用的各个部分共享 ●Worker –完成ucx的功能，可以在应用程序中调用的函数（不是单独执行的线程） ●Listener –接收连接请求 ●Ep –连接对象，在ep上请求发送和接收29

© 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 5、读写流程 6.6、topology 7、工作评估 7.1 client端 7.2 mds端 7.3 metaserver端 metaserver 子模块拆分 8、inode和dentry的内存估算 8.1 一台机器上能存放多少个inode和dentry 8.2 一台机器上建议的copyset数量 8.3 每个copyset建议管理存储容量的大小 1、背景 curvefs使用raft 63-1的Inode id。创建meta partition的时候，选择的3个meta node组成一个复制组。如何选择？论文上写的是按照存储节点的memory和disk usage来选的，通常选择内存和disk使用率最低的节点。 并去对应的meta node上去创建对应的meta partition。 如何选择partition的host，通过这个函数去选择。 func (c *Cluster)

C u r v e 质 量 、 监 控 与 运 维 秦 亦 1/33背景 01 02 03 04 Curve质量控制 Curve监控体系 Curve运维体系Curve 是网易针对块存储、对象存储、云原生数据库、EC等 多种场景自研的分布式存储系统：  高性能、低延迟  当前实现了高性能块存储，对接OpenStack和 K8s  网易内部线上无故障稳定运行近两年  已完整开源 Curve监控体系 Curve运维体系软件质量 软件质量的定义是：软件与明确地和隐含地定义的需求相一致的程度。 为了确保最终交付的软件满足需求，必须将质量控制贯穿于设计、开发到测试的整个流程中。 设计  设计流程  文档规范 开发  编码规范与提交流程  版本管理 测试  测试方法论  CI与异常测试 6/33设计流程 Curve团队采用敏捷开发模式，负责人在制定迭代计划时，确认哪些任务需要设计 符 合系统说明书的地方。它是一个黑盒测试，可以发现系统分析和设计中的错误。 Curve的系统测试一般是由QA来完成，包含：  常规测试，主要是新增功能的手工测试；  性能测试，将性能数据与基准对照，确定性能没有出现预期外的下降或提升；  稳定性测试，在正常压力下运行足够长的时间；  异常测试，在正常流程中注入一种软硬件异常；  混沌测试，大压力多级故障（随机组合软硬件异常）。

本地文件系统空间分配相关特性 局部性 尽量分配连续的磁盘空间，存储文件的数据。这一特性主要是针对HDD进行的优化，降低磁盘寻道时间。 延迟分配/Allocate-on-flush 在sync/flush之前，尽可能多的积累更多的文件数据块才进行空间分配，一方面可以提高局部性，另一方面可以降低磁盘碎片。 Inline file/data 几百字节的小文件不单独分配磁盘空间，直接把数据存放到文件的元数据中。 ffset, length），以offset为key进行排序（这里可以用map或者btree对所有的free extent进行管理）。 当前设计不考虑持久化问题，空间分配器只作为内存结构，负责空间的分配与回收。在初始化时，扫描文件系统所有inode中已使用的空间。 空间分配流程 在新文件进行空间分配时，随机选择level1中标记为0的块，先预分配给这个文件，但是并不表示这个块被该文件独占。© 。尽可能合并多个块分配给同一个文件。 空间回收 空间回收主要是一个extent合并的过程，有以下几种情况： 文件释放了一个完整的块，则直接将level1中对应的bit置为0。 文件释放了一小段空间，则尝试与level2中的extent进行合并。 如果合并之后是一个完整的块，则重新将level1中对应的bit置为0，同时删除该extent。 如果不能合并，则向level2中插入一个新的extent。 小文件处理

初稿(背景，调研，架构设计) 2021-03-30 李小翠 增加快照部分 2021-04-13 李小翠、陈威 补充元数据数据结构 2021-04-19 李小翠、吴汉卿、许超杰等 补充文件空间分配，讨论与确认 背景 调研 开源fs 性能对比 可行性分析 方案对比 对比结论 架构设计 卷和文件系统 元数据架构 文件系统快照 方案一：文件/目录级别快照 方案二：文件系统快照 关键点 元数据设计 现了块存储，向上提供块设备服务，CurveFS会基于此实现。第一阶段的目标是实现 满足数据库场景的文件接口。 调研 开源fs 当前对已有的开源分布式文件系统进行了调研，主要包括系统架构，元数据内存结构，元数据持久化，调研文档如下： chubaofs: ChubaoFS© XXX Page 3 of 14 1. 2. 3. moosefs: https://kms.netease list 加速，需要新的缓存结构 c. 扩展性/可用性/可靠性 依赖于第三方kv存储，目前是etcd CurveFS 单机内存元数据设计 类似 fastcfs 和 moosefs 的元数据设计方式，采用通用的 dentry，inode 两层映射关系，所有的元数据都缓存在内存中，持久化在 binlog 文件中，binlog采用定期dump的方式删除。基于这种方式的开发： a. 性能 加载：

2 Why ●为了减少使用cpu做内存copy，减少系统调用 ●发挥某些被操作系统屏蔽的功能，例如nvme write zero ●根据阿里《When Cloud Storage Meets RDMA》的说法 ●在100Gbps网络带宽时，内存带宽成为瓶颈 ●Intel Memory Latency Checker (MLC)测试得到的CPU内存带宽是 61Gbps10/17/22 3 3 RDMA可以减轻CPU负担 ●可以减少CPU操作网络通讯的开销 ●读写内存都由网卡进行offload ●应用程序不再通过系统调用在内核和用户态来回切换10/17/22 4 磁盘的读写 ●基于EXT4的存储引擎，依然需要通过系统调用来回切换 ●读写都需要CPU拷贝数据 ●不能发挥某些NVME的功能，例如write zero10/17/22 5 为什么用PFS ●对代码比较熟悉 ●找一个能管理裸盘，具有产品级可靠性的代码挺难的 ●PFS支持类POSIX文件的接口，与使用EXT4的存储引擎代码很像， 所以容易移植现有代码到PFS存储引擎 ●CurveBS对文件系统元数据的操作非常少，对文件系统的要求不高， 所以不需要元数据高性能，这方面PFS也合适10/17/22 6 对PFS的修改 ●基于阿里开源的PFS ●不再基于daemon模式，而是直接使用pfs core

raft的apply，直接在对应的chunk上写入数据。Curve文件存储RAFT应用 Curve文件存储 • 分布式文件系统 • 支持多挂载，提供close-to-open一致性 • 提供缓存加速，可使用内存、本地盘、云盘加速 • 存储后端可对接对象存储，降低成本 • 支持生命周期管理 Curve文件存储架构 • client：接受用户请求，采用fuse的方式挂载挂载使用。 • 元数据集群：mds • 要求存储的元数据的大小不超过内存的大小 • raft apply的请求，数据都在内存，直接修改 内存中的数据 • raft snapshot，为避免快照对正常操作的影 响，利用操作系统的内存写时复制技术， fork一个进程创建完整的状态机的内存快照， 后台遍历内存，把内存的数据持久化到本地 磁盘 基于memory的存储引擎 • 存储元数据量不受内存大小限制 • raft apply请求，数据保存在rocksdb，向 对rocksdb打快照。 • Curve文件系统也是使用copyset管理。 • 写日志的方式与Curve块存储基本一致，实现细节略有差异。 • raft apply和raft snapshot的实现和Curve块存储不同。 • metaserver有两套存储引擎，基于memory和基于rocksdb。 Curve文件系统与Curve块存储的实现区别CURVE的RAFT配置变更 心跳 • 通过心跳维持

link接口或rmdir接口时，需要判断unlink字段的当前值，当nlink字段大于1时，只减nlink字段就可以了，当nlink字段减到0时，才真正的执行删除inode。 目录的nlink字段与文件的nlink字段不同， ， 并且在目录下， ， 删除目录nlink相应的减1。 目录的nlink字段初始值为2 每创建一个新目录，nlink字段也会+1 目录不支持硬链接。 二是删除时lookup chubaofs实现了强制从freelist中移除inode的机制，同样是使用设置DeleteMarkFlag的方式。 chubaofs也实现了查询机制，来查询处于freelist当中的inode的情况，以便与运维，这一部分没有细看。 优点： 实现简单，开发代价小，且后续可以增加metaserver端打开(session)等机制，向着moosefs的演进也是可以的。 我们的整个架构设计本身就类似chu 是应对打开的文件被其他进程删除的情况 必须实现某种机制，可以查看清理trash中的inode。 孤儿节点只能在metaserver去定期清理，不会在client端，因为client会崩溃，也可能下线了，永远不再起来。所以实际的内存和外存中的inode的删除机制，必须是在metaserver中实现的。client端只是 进行nlink-1的操作。 不能完全依赖forget接口的调用来移除inode，因为client可能会崩溃，

中哈希表实现的优点？ 参考 前言 根据之前讨论的结果，元数据节点的架构如下图所示，这里涉及到两部分需要持久化/编码的内容： Raft Log：记录 operator log Raft Snapshot：将内存中的数据结构以特定格式 dump 到文件进行持久化© XXX Page 3 of 12 Raft Log +------+------------+-----+----------------+ 的方式解决在持久化的过程中，读写冲突的问题以及性能问题 实现 1、inode、entry 的编码 给 inode、dentry 增加编码函数 // 这里要尽可能减少 key/value 编码后的字节数，这样同样的内存可以存入较多的 key/value 对 序列化目前主要考虑以下 2 种，一种是参考 chubaofs 顺序编码，一种是利用 protobuf 直接序列化 顺序编码： 利用 prot only }© XXX Page 7 of 12 测试对比： 10 万条随机生成 inode 耗时 (MS) 内存 (KB) 顺序编码 13 5079 protobuf 序列化 81 4996 从对比结果来看，10 万条 inode 耗时相差不大（CPU 并不是瓶颈），内存 protobuf 消耗却更少，推介使用 protobuf 进行序列化 2、KVStore 将当前实现中的 MemoryDentryStorage

文件默认权限umask 用户&用户组 文件系统用户权限管理 对mode的管理 对ACL（Access Control Lists）的管理 ACL Access Entry保存在哪？ ACL的表示 内存中的ACL 是如何与具体的 Inode 相关联 如何存储和获取ACL信息 Inode权限校验 chmod、chown、setfacl、getfacl接口文件系统自己如何实现 结论： 参考文献： 一、Curvefs测试 For future use.© XXX Page 14 of 33 */ unsigned reserved[22]; }; 未实现任何权限检查的文件系统通常 应在内部添加此选项，可与参数‘allow_other’一起达到共享文件访问控制。© XXX Page 15 of 33 # LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so 在linux系统中， ，这些新的文件或目录都会有默认的访问权限 创建一个新的文件或者目录时 umask命令与文件和目录的默认访问权限有关，umask值则表明了需要从默认权限中去掉哪些权限来成 为最终的默认权限值。 root@pubbeta2-curve5:~# umask 0022 权限为777，文件为666，经过与umask作用，最终权限为755、644 默认目录 Windows Linux umask