© XXX Page 1 of 15 rename 接口实现方案（已实现，选用方案二）© XXX Page 2 of 15 1. 2. 3. 4. 1. 2. 1. 3. 1. 2. 背景 方案调研 Chubaofs Juicefs 方案实现 方案一：chubaofs 方案二：事务方案 方案三：利用 KV 自带的分布式事务 Q&A 1 2：rename A→C (A 存在，而 C 存在) 4. 当 2 个操作的 dentry 属于同一个 copyset 有什么不一样？ 背景 当前 curvefs 并没有实现 rename 接口，本文档是对 rename 接口实现的调研及方案设计。 rename 操作，主要操作的是 dentry，如 rename /dir1/file1 /dir2/file2，主要有 2 个步骤：(1) 删除 file1 file1 的 dentry，(2) 增加 file2 的 dentry（该 dentry 的 inodeid 等同 file1 的 inode id）。 关于 rename 接口的实现，主要调研了 chubaofs 和 juicefs，而 rename 的实现难点主要在于其原子性的保证。 方案调研 Chubaofs chubaofs 中的 rename 实现不是原子性的，它是通 用创建源文件的硬

© XXX Page 1 of 15 curve文件系统元数据proto（代码接口定义，已实现）© XXX Page 2 of 15 1、代码结构和代码目录 curve文件系统是相对于curve块设备比较独立的一块，在当前curve项目的目录下，增加一个一级目录curvefs，curvefs下有自己独立的proto\src\test。 2、文件系统proto定义 2.1 mds.proto

背景 概述 关键接口分析 init destroy lookup write read open create & mknod mkdir forget unlink rmdir opendir readdir getattr & setattr access rename symlink & readlink link flush & fsync 其他 功能分析 模块划分 接口设计 Cache设计 目前需细化Client端设计 CurveFS方案设计（总体设计，只实现了部分） 概述 CurveFS client 向上提供两层接口，分别是© XXX Page 3 of 11 对接fuse，提供通用文件系统接口。对于fuse接口，先前进行了一些调研，见FUSE调研 提供lib库，提供对接分布式数据库接口，这一部分，可参考polarfs的接口，如下图所示。 根据讨论，我们首先对接fuse的lowlevel 根据讨论，我们首先对接fuse的lowlevel operators，对于数据库的lib库接口，后续可以在此基础上再做一层对接。lowlevel operators接口一共45个，如下： +init +destroy +lookup +forget +getattr +setattr +readlink +mknod© XXX Page 4 of 11 +mkdir +unlink

ode和dentry结构，遗留了nlink和lookup count相关的内容还未实现，是不完备的。本文首先调研moosefs，chubaofs等分布式系统，参考并设计解决上述遗留问题。 当前删除接口代码如下：© XXX Page 3 of 15 CURVEFS_ERROR FuseClient::RemoveNode(fuse_req_t req, fuse_ino_t parent, nlink字段+1， 每删除一个hard link或指向的原文件时，nlink字段-1。© XXX Page 4 of 15 当nlink字段减到0时，才真正删除inode。所以在实现unlink接口或rmdir接口时，需要判断unlink字段的当前值，当nlink字段大于1时，只减nlink字段就可以了，当nlink字段减到0时，才真正的执行删除inode。 目录的nlink字段与文件的nlink字段不同， 指的是文件的访问计数。当文件/目录被打开时， ，该文件/目录仍然可以被打开的进程访问，不会造成崩溃或报错，我们的curvefs也需要实现 即使文件/目录已经被另一个进程删除了（nlink==0） 这样的语义。 这部分内容在fuse的相关接口中也有描述如下： /** * Forget about an inode * * This function is called when the kernel removes

file/data 空间分配 整体设计 空间分配流程 特殊情况 空间回收 小文件处理 并发问题 文件系统扩容 接口设计 RPC接口 空间分配器接口 背景 根据 ，文件系统基于当前的块进行实现，所以需要设计基于块的空间分配器，用于分配并存储文件数据。 CurveFS方案设计（总体设计，只实现了部分） 本地文件系统空间分配相关特性 局部性 尽量分配连续的磁盘空间，存储文件的数据。这一特性主要是针对HDD进行的优化，降低磁盘寻道时间。 of 11 1. 2. 3. 以下图为例：file1新申请了2MiB的空间。首先从level1中随机选一个标记为0的块分配出去，然后将这一个块中的前2MiB空间分配给这个文件，剩余部分加入到level2中的list中。 后续，file1再次追加写入2MiB数据，此时申请空间时，需要附带上file1最后一个字节数据在底层存储的位置，再加1（期望申请的地址空间起始offset）。以图中为例，则附带的值为30MiB。 所以可以参考chubaofs，对大小文件区分不同的分配逻辑。同时，将文件系统的空间划分成两个部分，一部分用于小文件的空间分配，另一部分用于大文件分配。两部分空间是相对的，一部分用完后，可以申请另 一部分的空间。比如，大文件部分的空间完全分配出去，则可以继续从小文件空间进行分配。 用于小文件空间分配的部分，空闲空间可以用extent来表示。 小文件在空间分配时，也需要考虑尽量分配连续的地址空间。

© XXX Page 1 of 14 CurveFS方案设计（总体设计，只实现了部分）© XXX Page 2 of 14 时间 修订人 修订内容 2021-03-23 李小翠 初稿(背景，调研，架构设计) 2021-03-30 李小翠 增加快照部分 2021-04-13 李小翠、陈威 补充元数据数据结构 2021-04-19 李小翠、吴汉卿、许超杰等 补充文件空间分配，讨论与确认 背景 为更好的支持云原生的场景，Curve需要支持高性能通用文件系统，其中高性能主要是适配云原生数据库的场景。当前Curve是实现了块存储，向上提供块设备服务，CurveFS会基于此实现。第一阶段的目标是实现 满足数据库场景的文件接口。 调研 开源fs 当前对已有的开源分布式文件系统进行了调研，主要包括系统架构，元数据内存结构，元数据持久化，调研文档如下： chubaofs: ChubaoFS© XXX Page 3 of 能相比单机要弱一些 b. 扩展性/可用性/可靠性 使用 multi-raft, 扩展性、可用性和可靠性与元数据节点一致 对比结论 CurveFS 近期要能支持mysql所要接口，长期需要支持通用文件接口。 kv 虽然改造简单，短期内对基本功能的支持没有问题，但这个架构不利于 Curve 长期的规划和演进，因此选择通用的 dentry，inode 两层映射的元数据结构。对于 fs© XXX

●不能发挥某些NVME的功能，例如write zero10/17/22 5 为什么用PFS ●对代码比较熟悉 ●找一个能管理裸盘，具有产品级可靠性的代码挺难的 ●PFS支持类POSIX文件的接口，与使用EXT4的存储引擎代码很像， 所以容易移植现有代码到PFS存储引擎 ●CurveBS对文件系统元数据的操作非常少，对文件系统的要求不高， 所以不需要元数据高性能，这方面PFS也合适10/17/22 ●不再基于daemon模式，而是直接使用pfs core api ●依然向外提供管理工具, 例如 pfs ls、cp、rm等 ●增加spdk驱动10/17/22 7 新增PFS接口 ●增加pfs_pwritev和pfs_preadv接口 ●ssize_t pfs_preadv(int fd, const struct iovec *iov, int iovcnt, off_t offset); ●ssize_t iovcnt, off_t offset); ●IO vector的接口主要是为了与brpc的iobuf对接，iobuf由若干地址不连 续的block组成，一次IO提交可以提高效率。10/17/22 8 PFS+SPDK 的部分读写的实现 ●某些盘只支持4k单位读写，但是CurveBS支持512字节读写 ●可能存在部分写的并发冲突 ●引入并发的range lock解决冲突10/17/22

0（2025-02-17 发布）或更高版本并在所有项目的 Cargo.toml 文件中通过 edition = "2024"将其配置为使用 Rust 2024 edition 惯用法。请查 看第一章的 “安装” 部分了解如何安装和升级 Rust。 本书的英文原版 HTML 格式可以在 https://doc.rust-lang.org/stable/book/ 在线阅读；使用 rustup 安装的 Rust 完成各种任务，包括命令行工具、Web 服务、 DevOps 工具、嵌入式设备、音视频分析与转码、加密货币、生物信息学、搜索引擎、物联网 （IOT）程序、机器学习，甚至是 Firefox 浏览器的重要部分。 开源开发者 Rust 适合那些希望构建 Rust 编程语言、社区、开发工具和库的开发者。我们非常欢迎你为 Rust 语言作出贡献。 7/562Rust 程序设计语言 简体中文版 重视速度和稳定性的开发者 懂。本书的重点不是程序设计本身，也不是程序设计思维。如果你完全没学过编程，建议你先 阅读专门介绍程序设计的书籍。 如何阅读本书 本书大体上假设你按从头到尾的顺序阅读。后面的章节建立在前面章节概念的基础上。前面的 章节可能不会深入介绍部分主题，而是留待后续章节重新讨论。 本书分为两类章节：概念章节和项目章节。在概念章节中，我们学习 Rust 的某个方面。在项 目章节中，我们应用目前所学的知识一同构建小型程序。第二、十二和二十一章是项目章节；

读写缓存分离 缓存层级 对外接口 后台刷数据线程 本地磁盘缓存 关键数据结构 详细设计 Write流程 Read流程 ReleaseCache流程 Flush流程 FsSync流程 后台流程 poc测试验证 背景 基于s3的daemon版本基于基本的性能测试发现性能非常差。具体数据如下： 通过日志初步分析有2点原因© XXX Page 3 of 9 1.append接口目前采用先从s3 ge unk，然后通过offset~len找到是否有合适的datacache或者new datacache。 对外接口 流程上对于读写缓存有影响的接口包括：write，read，releaseCache，flush，fssync。后面会详细介绍这些接口流程。这里不需要提供truncate接口，可以由client直接修改inode的len，由metaserver的碎片整 理（马杰负责）模块进行truncate的无效数据清理 he有交集（包括刚好是边界的情况）即可写。 4.2 同时计算后续的多个DataCache是否和chunkPos~len有交集，如果有则一并获取 5. 如果有可写的DataCache，则调用Write接口将数据合并到DataCache中； ，加入到ChunkCacheManager的Map中。 如果没有可写的DataCache则new一个 5.完成后返回成功。 Read流程 1.根据请求offset，计算出对应的chunk

© XXX Page 1 of 23 open flags 调研（已实现）© XXX Page 2 of 23 open接口原型 open flags flags定义 flags的含义 libfuse open open flags 在curvefs上的测试 open flags 实现方式 整体flags支持方案 具体flag的实现方案 O_TRUNC I/O模式类 O_DIRECT O_SYNC O_SYNC, O_DSYNC O_NONBLOCK(O_NDELAY ), FASYNC, O_TMPFILE 结论 参考文献 open接口原型 # man page open, openat, creat - open and possibly create a file #include int open(const char *pathname, int flags); 文件描述符，防止父进程泄露打开的文件给子进程。 O_CLOEXEC O_PATH: 使用 O_PATH 将不会真正打开一个文件，而只是准备好该文件的文件描述符，而且如果使用该标志位的话系统会忽略大部分其他的标志位(除了O_CLOEXEC, O_DIRECTORY, O_NOFOLLOW)。特别是如果配合使用 O_NOFOLLOW，那么遇到符号链接的时候将会返回这个符号链接本身的文件描述符，而非符号链接所指的对象。