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的打开情况？ client版本对删除unlink和rmdir的设计只有简单的删除inode和dentry结构，遗留了nlink和lookup count相关的内容还未实现，是不完备的。本文首先调研moosefs，chubaofs等分布式系统，参考并设计解决上述遗留问题。 当前删除接口代码如下：© XXX Page 3 of 15 CURVEFS_ERROR FuseClient::RemoveNode(fuse_req_t 上会比moosefs复杂，需要引入一些额外的复杂性。 由于是按目录管理trash，那么必须是两个trash（其中一个是reserve）以区分两种不同的情况。 chubaofs chubaofs的方案如下： chubaofs实现了类似trash的机制，称为freelist， 当inode被unlink时，client会发送UnlinkInodeRequest， 对应的metase

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的管理 2.3、meta partition和inode以及dentry的对应关系？ 3、cu 这里需要重新考虑curvefs的copyset和fs的元数据分片的对应关系。© XXX Page 3 of 19 2、chubaofs的元数据管理 chubaofs（补充链接）的元数据也是采用的raft的方式进行管理，可以借鉴一下chubaofs的元数据的分片策略。 通过分析chubaofs的源代码。chubaofs的用volume管理一个文件系统，每个volume有若干meta partition和data partition。meta y信息。 创建一个文件系统时，如何初始化meta partition？ master\cluster.go， chubaofs的文件系统使用volume的来表示，在创建一个文件系统的时候，会创建3个meta partition和10个data partition。chubaofs的data partition的功能我们使用curve块设备替换。meta partition的创建，以及meta

XXX Page 2 of 15 1. 2. 3. 4. 1. 2. 1. 3. 1. 2. 背景 方案调研 Chubaofs Juicefs 方案实现 方案一：chubaofs 方案二：事务方案 方案三：利用 KV 自带的分布式事务 Q&A 1. 是否需要实现跨文件系统的 rename 操作？ 2. 在多客户端情况下，是否需要加锁来保证其原子性？ dentry（该 dentry 的 inodeid 等同 file1 的 inode id）。 关于 rename 接口的实现，主要调研了 chubaofs 和 juicefs，而 rename 的实现难点主要在于其原子性的保证。 方案调研 Chubaofs chubaofs 中的 rename 实现不是原子性的，它是通 用创建源文件的硬连接，然后删除源文件的方式来实现的，主要有以下 4 步 ： 将源文件的 将源文件的 nlink 加一 创建目标文件的 dentry 删除源文件的 dentry 将源文件的 nlink 减一 而每一步骤都有可能出错，chubaofs 针对以上的 4 步骤中出现的错误处理如下： 步骤 1 出错，啥事都没发生 步骤 2 出错，等同于创建硬连接出错，恢复机制如下： 将源文件的 nlink 减一 步骤 3 出错，相当于创建了硬链接，但是没有删除源文件，此时源文件和目标文件同时存在，恢复机制如下：

。第一阶段的目标是实现 满足数据库场景的文件接口。 调研 开源fs 当前对已有的开源分布式文件系统进行了调研，主要包括系统架构，元数据内存结构，元数据持久化，调研文档如下： chubaofs: ChubaoFS© XXX Page 3 of 14 1. 2. 3. moosefs: https://kms.netease.com/team/km_curve/article/27786 com/team/km_curve/article/27909 性能对比 并对以上文件系统在相同环境进行了元数据节点性能测试： 。测试结果c开发的moosefs和fastcfs元数据性能远优于go开发的chubaofs和c开发的cephfs，理论上分析这个结果是合理的，分布式的元数据设 调研测试 计会涉及到多次rpc的交互。这里需要确认的一点是：我们需要怎样的元数据节点的性能？ 可行性分析 方案对比 master-slave 的方式，master 以同步方式调用 slave，slave 在内存中也缓存了全部元数据信息 master-slave 多副本数据 CurveFS 分布式元数据设计 类似 chubaofs 的元数据设计方式，同样是采用 dentry，inode 两层映射关系，所有的元数据都缓存在内存中。元数据是分片的，使用 multi-raft 持久化元数据以及保证多副本数据一致性。基于这种方式开发：

+readdir +releasedir +fsyncdir +statfs +setxattr chubaofs +getxattr chubaofs +listxattr chubaofs +removexattr chubaofs +access +create +getlk +setlk +bmap +ioctl 硬链接相关目前可先不实现。© XXX Page 9 of 11 flush & fsync 缓存的问题暂时先不考虑太细，目前默认数据和元数据直接存储到底层，这两个也可先不实现 其他 xattr系列接口，chubaofs都没实现，目前先不考虑 fuse高版本新增的接口如lseek等，在低版本中没有，因此不是必须接口，也先不实现。 功能分析 根据上述接口的分析，可以把client端的功能进行汇总，client需实现的功能主要有：

同步I/O：强制刷新内核缓冲区到输出文件© XXX Page 21 of 23 对chubaofs和cephfs代码调研中发现在write中判断如果是直接IO则调用flush操作，但是对具体flush内容主要是对文件系统自己缓存的内容进行刷盘，没有发现对应内核缓冲区flush的相关设置或调用等。© XXX Page 22 of 23 // chubaofs writeflush func cfs_write(id C offset, size); ... } } O_NONBLOCK(O_NDELAY ), FASYNC, O_TMPFILE 查看的几个分布式系统都没有进行实现包括cephfs、chubaofs、moosefs、fastcfs。具体实现后续可以再深入看看。© XXX Page 23 of 23 结论 1，需要实现file_truncate接口来支持O_TRUNC flag（优先级高）。

如果不能合并，则向level2中插入一个新的extent。 小文件处理 大量小文件的情况下，按照上述的分配策略，会导致level1的bitmap标记全为1，同时level2中也会有很多extent。 所以可以参考chubaofs，对大小文件区分不同的分配逻辑。同时，将文件系统的空间划分成两个部分，一部分用于小文件的空间分配，另一部分用于大文件分配。两部分空间是相对的，一部分用完后，可以申请另 一部分的空间。比如，大文

inode、dentry 增加编码函数 // 这里要尽可能减少 key/value 编码后的字节数，这样同样的内存可以存入较多的 key/value 对 序列化目前主要考虑以下 2 种，一种是参考 chubaofs 顺序编码，一种是利用 protobuf 直接序列化 顺序编码： 利用 protobuf（SerializeToString）进行序列化© XXX Page 6 of 12 //

name) 全内存 chunk → hashtable(chunk id) log + dump record 差 否 chunk 链式多副本 overwirte有数据不一致风险 chubaofs（cfs） 有元数据服务器 inode → b tree(key ino) dentry → b tree (key parentIno + name) extent → B+ tree

Dragonfly Linux 基金会 CNCF 阿里 2018 年 10 月 2020 年 4 月 KubeEdge Linux 基金会 CNCF 华为 2019 年 3 月 2020 年 9 月 ChubaoFS Linux 基金会 CNCF 京东 2020 年 1 月 Volcano Linux 基金会 CNCF 华为 2020 年 4 月 BFE Linux 基金会 CNCF 百度 2020 年