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

curvefs client 删除文件和目录功能设计 背景 相关调研 moosefs chubaofs 方案设计思考 1. Trash机制是实现1个(类似chubaofs)，还是2个（类似moosefs）？ 2. Trash 放在哪里? 3. 是否需要做 session 机制（在 metaserver 打开），来维护 inode 的打开情况？ • 方案设计 • Trash机制： client版本对删除unlink和rmdir的设计只有简单的删除inode和dentry结构，遗留了nlink和lookup count相关的内容还未实现，是不完备的。本文首先调研moosefs，chubaofs等分布式系统，参考并设计解决上述遗留问题。 当前删除接口代码如下： CURVEFS_ERROR FuseClient::RemoveNode(fuse_req_t req, fuse_ino_t oosefs复杂，需要引入一些额外的复杂性。 2. 由于是按目录管理trash，那么必须是两个trash（其中一个是reserve）以区分两种不同的情况。 ## chubaofs chubaofs的方案如下： chubaofs实现了类似trash的机制，称为freelist， 当inode被unlink时，client会发送UnlinkNodeRequest，对应的metasever接收

|---|---|---|---| |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的对应关系 配。 这里需要重新考虑curvefs的copyset和fs的元数据分片的对应关系。 ## 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的数据分块功能我们使用curve块设备替换。meta partition的创建，以及meta partition的管理的，下面会详细分析一下。

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

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

2104164bafcd23ef5dfd30744/p21_1.jpg) 对chubaofs和cephfs代码调研中发现在write中判断如果是直接IO则调用flush操作，但是对具体flush内容主要是对文件系统自己缓存的内容进行刷盘，没有发现对应内核缓冲区flush的相关设置或调用等。 // chubaofs writeflush func cfs_write(id C.int64_t, fd (f->flags & O_DIRECT) _flush_range(in, offset, size); } } 查看的几个分布式系统都没有进行实现包括cephfs、chubaofs、moosefs、fastcfs。具体实现后续可以再深入看看。 ## 结论 1，需要实现file_truncate接口来支持O_TRUNC flag（优先级高）。 2，待curvefs支持

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

inode、dentry 增加编码函数 // 这里要尽可能减少 key/value 编码后的字节数，这样同样的内存可以存入较多的 key/value 对 • 序列化目前主要考虑以下 2 种，一种是参考 chubaofs 顺序编码，一种是利用 protobuf 直接序列化 ## 顺序编码： ![Image](/uploads/documents/8/5/d/d/85dd03b9408f6e1cf2e67a368b5b940b/p5_1

id)|log + dump record|差|否|chunk|链式多副本|overwrite 有数据不一致风险| |---|---|---|---|---|---|---|---|---|---| |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年6月|||