© XXX Page 1 of 15 curvefs client 删除文件和目录功能设计© XXX Page 2 of 15 背景 相关调研 moosefs chubaofs 方案设计思考 1.Trash机制是实现1个(类似chubaofs)，还是2个（类似moosefs）？ 2. Trash放在哪里？ 3. 是否需要做session机制（在metaserver打开），来维护inode的打开情况？ 打开情况？ 方案设计 Trash机制： Session机制： 遗留问题 工作量评估 背景 目前curvefs client版本对删除unlink和rmdir的设计只有简单的删除inode和dentry结构，遗留了nlink和lookup count相关的内容还未实现，是不完备的。本文首先调研moosefs，chubaofs等分布式系统，参考并设计解决上述遗留问题。 当前删除接口代码如下：© (fuse_req_t req, fuse_ino_t parent, const char *name); 其中的注释内容总结如下： 当lookup count在fuse_reply_entry和fuse_reply_create时增加1 当内核移除其inode cache时，会调用forget，此时lookup count需要减nlookup（forget的参数） 当umount时，所有lookup

partition的管理 2.3、meta partition和inode以及dentry的对应关系？ 3、curvefs的copyset和fs的对应关系 3.1 如何获取inodeid 3.2 copyset fs共用吗？ 3.3 copyset个数是否可以动态调整？ 4、curvefs的topo信息 5、curvefs mds和metaserver的心跳 6、详细设计 6.1 创建fs 6 metaserver 子模块拆分 8、inode和dentry的内存估算 8.1 一台机器上能存放多少个inode和dentry 8.2 一台机器上建议的copyset数量 8.3 每个copyset建议管理存储容量的大小 1、背景 curvefs使用raft作为元数据一致性的保证。为了提高元数据的可扩展性和并发处理能力，采用元数据分片的方式管理inode和dentry的元数据。inode的分片依据是fsid 这里需要重新考虑curvefs的copyset和fs的元数据分片的对应关系。© XXX Page 3 of 19 2、chubaofs的元数据管理 chubaofs（补充链接）的元数据也是采用的raft的方式进行管理，可以借鉴一下chubaofs的元数据的分片策略。 通过分析chubaofs的源代码。chubaofs的用volume管理一个文件系统，每个volume有若干meta partition和data partition。meta

(*init) (void *userdata, struct fuse_conn_info *conn); 根据挂载信息，从mds获取文件系统信息（或superblock），块分配器（bitmap）和root inode所在的copyset、 metaserver ip等信息 去metaserver获取文件系统信息（super block），缓存到client端。 destroy void (*destroy) 清理init缓存的文件系统信息。 lookup void (*lookup) (fuse_req_t req, fuse_ino_t parent, const char *name); 根据parent inode id和name从denty缓存中找到对应的denty结构； 如果dentry缓存中不存在对应的inode，则从mds根据parent inode id获取parent inode 所在copyset，metaserver ，则会出错，用此测试文件是否存在，如果不存在则创建此文件。 O_TRUNC 如果文件存在，且为只写或只读打开，则将其文件长度截短为0 O_DSYNC sync数据和必要元数据（不影响读取刚写入的数据） O_SYNC sync数据和所有元数据 O_DIRECTORY 目录 O_DIRECT 直接IO open的主要逻辑： 根据inode id，从mds获取inode所在copyset，metaserver

2、其他文件系统的调研总结 3、各内存结构体 4、curve文件系统的元数据内存组织 4.1 inode定义： 4.2 dentry的定义： 4.3 内存组织 5 元数据分片 5.1 分片方式一：inode和dentry都按照parentid分片 5.1.1 场景分析 查找：查找/A/C。 创建：/A/C不在，创建/A/C 删除文件：删除/A/C 删除目录：删除/A rename：rename /A/C到/B/E extent，属于一个文件 partition append→ master slave协议 overwrite → raft 更适合大文件顺序写 fastcfs 有元数据服务器 inode和dentry放一个结构体。 inode → hashtable（key是ino，全局） dentry → skip list （key是name，每个目录下一个） 计算出来的 binlog，随时间会越来越大 无中心化服务器 dht算法 hash 扩展时大量迁移 client缓存 inode→ hashtable(gfid) dentry→ hashtable(name) inode扩展属性字段 和写数据一样 好 写多份 overwirte有数据不一致风险 curve 有元数据服务器 lru cache缓存 kv → hashtable(key parent inode + name)

并对以上文件系统在相同环境进行了元数据节点性能测试： 。测试结果c开发的moosefs和fastcfs元数据性能远优于go开发的chubaofs和c开发的cephfs，理论上分析这个结果是合理的，分布式的元数据设 调研测试 计会涉及到多次rpc的交互。这里需要确认的一点是：我们需要怎样的元数据节点的性能？ 可行性分析 方案对比 根据上述调研和测试结果，我们考虑了三种curvefs的元数据设计方案： CurveFS namespace 开发： a. 功能 软/硬链接：目前是都不支持的。软链接可以通过标识文件类型解决；由于 prefix + parentid + filename 作为 key , filename 直接和 fileInfo 关联，硬链接无法支持 b. 性能 list：list在通用文件系统中是很常见的操作，目前 curve 的元数据缓存使用的 lru cache，因此 list 只能依赖 etcd range 获取方式。如果需要对 list 加速，需要新的缓存结构 c. 扩展性/可用性/可靠性 依赖于第三方kv存储，目前是etcd CurveFS 单机内存元数据设计 类似 fastcfs 和 moosefs 的元数据设计方式，采用通用的 dentry，inode 两层映射关系，所有的元数据都缓存在内存中，持久化在 binlog 文件中，binlog采用定期dump的方式删除。基于这种方式的开发：

C u r v e 存 储 中 的 工 程 实 践 陈威Curve介绍 01 02 raft和braft 03 raft在Curve中的应用 05 Q&A 04 Curve对raft的优化项目背景 Curve是一个 高性能、更稳定、易运维 的 云原生 分布式存储系统，支持 块存储 和 文件存储 2018~2021 Curve块存储 2021~2022 Curve文件存储 • 数据库 云原生 AI训练 大数据 社区生态Curve介绍 01 02 raft和braft 03 raft在Curve中的应用 05 Q&A 04 Curve对raft的优化RAFT协议简介 什么是raft • raft 是一种新型易于理解的分布式一致性复制协议，由斯坦福大学的Diego Ongaro和John Ousterhout提出，《In Search of an Understandable Algorithm(Extended Version)》 • raft 是一种Leader-Based的Multi-Paxos变种，提供了更完整更清晰的协议描述，更容易理解和实现。 • raft可以解决分布式理论中的CP，即一致性和分区容忍性 • 大多数副本成功即可返回成功 • 速度取决于写的较快的大多数RAFT协议简介 • Leader：负责从客户端接受日志，把日志复制到其 他服务器，当保证安全性的时候告诉其他服务器应用

对mode的管理 对ACL（Access Control Lists）的管理 ACL Access Entry保存在哪？ ACL的表示 内存中的ACL 是如何与具体的 Inode 相关联 如何存储和获取ACL信息 Inode权限校验 chmod、chown、setfacl、getfacl接口文件系统自己如何实现 结论： 参考文献： 一、Curvefs测试 代码：https://github 功才能允许操作 。 。 。 内核执行标准的 UNIX 权限检查 如果文件系统在打开设备 fd 时的初始功能协商期间启用了 ACL 支持，则此挂载选项将被隐式激活。 在这种情况下，内核执行 ACL 和标准的 unix 权限检查 疑问：协商期间do_init()中的启用ACL的flags如何设置？ 初始化时的 通过 ： 功能协商 init()函数实现© XXX Page 9 of 33 // libfuse wanghai01@pubbeta1-nostest2:/tmp/fsmount$ cat hello.txt hello world 结论：fuse挂载时使用'default_permissions' 和 ‘allow_other’ ；或者可以在用户态文件系统中自由的实现访问控制策略。 可以达到共享文件系统下的基于内核权限检查的文件访问控制 二、文件系统权限管理© XXX Page 16 of 33

MDS 陈威Curve 是高性能、高可用、高可靠的分布式存储系统 • 高性能、低延迟 • 可支撑储场景：块存储、对象存储、云原生数据库、EC等 • 当前实现了高性能块存储，对接OpenStack和 K8s 网易内部线上无故障稳定运行一年多 • 已开源 • github主页： https://opencurve.github.io/ • github代码仓库： https://github copyset信息等。 • Scheduler: 调度模块。用于自动容错和负载均衡。TOPOLOGY topology用于管理和组织机器，利用底层机器的放置、网络的规划以面向业务提供如下功能和非功能需求。 1. 故障域的隔离：比如副本的放置分布在不同机器，不同机架，或是不同的交换机下面。 2. 隔离和共享：不同用户的数据可以实现固定物理资源的隔离和共享。 • pool: 用于实现对机器资源进行物理隔离，server不能跨 chunk是数据分片的最小单元。 segment 和 chunk的关系如下图:NAMESERVER Namespace的文件的目录层次关系如右图。 文件的元数据以KV的方式存储。 • Key：ParentID + “/”+ BaseName； • Value：自身的文件ID。 这种方式可以很好地平衡几个需求： • 文件列目录：列出目录下的所有文件和目 录 • 文件查找：查找一个具体的文件 •

04 快照和克隆的特点 快照克隆服务器架构 快照的实现 05 克隆的实现CURVE基本架构 • 元数据节点 MDS • 管理和存储元数据信息 • 感知集群状态，合理调度 • 数据节点 Chunkserver • 数据存储 • 副本一致性，raft • 客户端 Client • 对元数据增删改查 • 对数据增删改查 • 快照克隆服务器 • 快照 • 克隆快照和克隆的特点 增量转储，第一次全量转储s3之后，后续只需转储增量部分 • 高可用，快照任务中断自动拉起继续转储快照和克隆的特点 • 克隆的定义 • 克隆是指从卷复制出卷的功能，提供快速的复制卷的能力。 • 这里的克隆还包括从快照回滚的功能 • 克隆的特点 • 支持Lazy和非Lazy两种模式克隆 • 支持从快照克隆和从镜像（卷）克隆 • 支持从快照回滚 • 高可用，克隆任务中断自动拉起继续克隆快照克隆服务器架构 CloneService: • 任务管理层负责调度SnapshotTask和CloneTask，并向上提供如 cancel task等功能。 SnapshotTaskManager & CloneTaskManager: • 快照克隆核心模块，负责向下调用DataStore，MetaStore等底层 模块，实现快照和克隆的具体功能。 SnapshotCore & CloneCore:快照克隆服务器架构

当前实现了高性能块存储，对接OpenStack和 K8s  网易内部线上无故障稳定运行近两年  已完整开源 • github主页： https://opencurve.github.io/ • github代码仓库： https://github.com/opencurve/curve Curve 3/33为用户服务 作为一个复杂的大型分布式存储系统，Curve 需要利用科学的方法论和专业的工具，在整个 （易部署、易升级、自治） ✓ 运维工具（部署工具、管理工具） 4/33背景 01 02 03 04 Curve质量控制 Curve监控体系 Curve运维体系软件质量 软件质量的定义是：软件与明确地和隐含地定义的需求相一致的程度。 为了确保最终交付的软件满足需求，必须将质量控制贯穿于设计、开发到测试的整个流程中。 设计  设计流程  文档规范 开发  编码规范与提交流程  版本管理 小需求（改动小）将实现思路记录到任务管理系统中（JIRA），即可进行开发；  大需求（新模块、复杂功能）需要输出独立设计文档，并进行评审；对于功能或 性能影响较大的功能，还需要进行POC验证；评审和验证通过后才能启动开发 工作。 小需求 实现思路 开发 大需求 设计文档 POC 开发 7/33设计文档规范 设计文档需要具备以下内容：  修订记录  审批记录  系统介绍 