© 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

读写缓存分离 缓存层级 对外接口 后台刷数据线程 本地磁盘缓存 关键数据结构 详细设计 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，那么遇到符号链接的时候将会返回这个符号链接本身的文件描述符，而非符号链接所指的对象。

EchoRequest EchoResponse5 BRPC简介 ●Channel类 –代表一个连接，Client通过Channel发 送请求和接收应答 ●Server类 –代表一个服务器，可以注册不同的 接口服务，例如上面的EchoService6 BRPC SERVER7 BRPC SERVER8 BRPC client9 BRPC EndPoint EndPoint是一个代表通讯地址的数据结构 table –epoll event loop – memory register cache –config file24 UCT ●特点是比较原始，开销小，但是没有很强的功能 ●是网络接口层，主要功能是网卡发现和远程内存传输支持，提供component查询和 memory domain的打开 ●一个component包含若干 memory domain resource,一个memory UCX 编程的一些基本概念 ●Context –收集机器资源（内存，网卡等)，在应用的各个部分共享 ●Worker –完成ucx的功能，可以在应用程序中调用的函数（不是单独执行的线程） ●Listener –接收连接请求 ●Ep –连接对象，在ep上请求发送和接收29 UCP 消息接口类型 ●Active message –速度最快，被brpc使用作为消息传递 –消息通过回调函数接收

Access Entry保存在哪？ ACL的表示 内存中的ACL 是如何与具体的 Inode 相关联 如何存储和获取ACL信息 Inode权限校验 chmod、chown、setfacl、getfacl接口文件系统自己如何实现 结论： 参考文献： 一、Curvefs测试 代码：https://github.com/cw123/curve/tree/fs_s3_joint_debugging 环境：test2 text ACL的使用规则和原理： ACL是由一系列的Access Entry所组成的，每一条Access Entry定义了特定的类别可以对文件拥有的操作权限。Access Entry有三个组成部分：Entry tag type, qualifier (optional), permission。 # example an Access Entry user:john:rw- group:dev:r-- Ext4_inode ，每个 Inode 大小为 ext4_super_block 中指定的 s_inode_size, 然而一个 Inode 不一定用到这么多的大小，节点信息只用到 128 个字节的空间。剩下的部分作为扩展文件属性 (Xattr)，扩展属性内部是由一个扩展属性头和若干个扩展属性实体项构成的。© XXX Page 29 of 33 // fs/ext4/xattr.h struct ext4_xattr_header