© XXX Page 1 of 24 Curve文件系统元数据管理（已实现）© XXX Page 2 of 24 1. 2. 3. 4. Inode 1、设计一个分布式文件系统需要考虑的点： 2、其他文件系统的调研总结 3、各内存结构体 4、curve文件系统的元数据内存组织 4.1 inode定义： 4.2 dentry的定义： 4.3 内存组织 5 元数据分片 照parentid分片 5.1.1 场景分析 查找：查找/A/C。 创建：/A/C不在，创建/A/C 删除文件：删除/A/C 删除目录：删除/A rename：rename /A/C到/B/E symbolic link： hardlink：生成一个hardlink /B/E，指向文件/A/C list：遍历/A目录 5.1.2 好处 5.1.2 问题 5.2 分片方式二：Inode按照i hardlink：生成一个hardlink /B/E，指向文件/A/C 6、curve文件系统的多文件系统的设计 1、设计一个分布式文件系统需要考虑的点： 文件系统的元数据是否全缓存？ 元数据持久化在单独的元数据服务器上？在磁盘上？在volume上？ inode+dentry方式？当前curve块存储的kv方式？ 是否有单独的元数据管理服务器？ 2、其他文件系统的调研总结 fs 中心化元数据 内存namespace元数据

11 Curve文件系统空间分配方案（基于块的方案，已实现）© XXX Page 2 of 11 背景 本地文件系统空间分配相关特性 局部性 延迟分配/Allocate-on-flush Inline file/data 空间分配 整体设计 空间分配流程 特殊情况 空间回收 小文件处理 并发问题 文件系统扩容 接口设计 RPC接口 空间分配器接口 背景 根据 ，文件系统基于当前的 ，文件系统基于当前的块进行实现，所以需要设计基于块的空间分配器，用于分配并存储文件数据。 CurveFS方案设计（总体设计，只实现了部分） 本地文件系统空间分配相关特性 局部性 尽量分配连续的磁盘空间，存储文件的数据。这一特性主要是针对HDD进行的优化，降低磁盘寻道时间。 延迟分配/Allocate-on-flush 在sync/flush之前，尽可能多的积累更多的文件数据块才进行空间分配，一方面可以提高局部性，另一方面可以降低磁盘碎片。 file/data 几百字节的小文件不单独分配磁盘空间，直接把数据存放到文件的元数据中。 针对上述的本地文件系统特性，Curve文件系统分配需要着重考虑 。 局部性 虽然Curve是一个分布式文件系统，但是单个文件系统的容量可能会比较大，如果在空间分配时，不考虑局部性，inode中记录的extent数量很多，导致文件系统元数据量很大。© XXX Page 3 of 11 假如文件系统大小为1PiB，

© 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的打开情况？ ret; } 存在两个问题: 一是删除时nlink字段未考虑： 文件的nlink用于实现hard link。 hard link使用nlink字段表示文件的link的引用计数，第一次创建文件是nlink字段为1。每创建一个新的指向该文件的hard link时,nlink字段+1， 每删除一个hard link或指向的原文件时，nlink字段-1。© XXX Page 4 of 15 当nl 删除inode。 目录的nlink字段与文件的nlink字段不同， ， 并且在目录下， ， 删除目录nlink相应的减1。 目录的nlink字段初始值为2 每创建一个新目录，nlink字段也会+1 目录不支持硬链接。 二是删除时lookup count未考虑： lookup count 指的是文件的访问计数。当文件/目录被打开时， ，该文件/目录仍然可以被打开的进程访问，不会造成崩溃或报错，我们的curvefs也需要实现

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

© XXX Page 1 of 12 元数据持久化© XXX Page 2 of 12 前言 Raft Log Raft Snapshot 持久化文件 key_value_pairs 其他说明 实现 1、inode、entry 的编码 2、KVStore Q&A 单靠 redis 的 AOF 机制能否保证数据不丢失? redis 的高可用、高可扩方案？ redis + muliraft 根据之前讨论的结果，元数据节点的架构如下图所示，这里涉及到两部分需要持久化/编码的内容： Raft Log：记录 operator log Raft Snapshot：将内存中的数据结构以特定格式 dump 到文件进行持久化© XXX Page 3 of 12 Raft Log +------+------------+-----+----------------+---------+----------+ ---+----------------+---------+ 持久化文件 字段 字节数 说明 CURVEFS 7 magic number（常量字符 "CURVEFS"），用于标识该文件为 curvefs 元数据持久化文件 version 4 文件版本号（当文件格式变化时，可以 100% 向后兼容加载旧版持久化文件） size 8 键值对数量 key_value_pairs / 键值对（当

当前，s3客户端在写底层存储的时候是直接写入远端对象存储，由于写远端时延相对会较高，所以为了提升性能，引入了写本地缓存盘方案。也即要写底层存储时，先把数据写到本地缓存硬盘，然后再把本地缓存 硬盘中的数据异步上传到远端对象存储。 方案设计© XXX Page 3 of 9 S3模块接收到写入后先写入写内存缓存页，如果满足持久化的条件后，那么则准备持久化。 如果未配置本地硬盘作为写缓存，那么直接持 到本地硬盘写缓存目录中。文件写入本地硬盘写缓存目录后，从本地硬盘读目录© XXX Page 4 of 9 做一个硬链接链接到该文件。 本次io在本地硬盘写入好之后，异步上传模块会适时把本地硬盘写缓存目录中的文件上传到远端对象存储集群，上传成功后，删除本地写缓存目录中的对应文件。 同时，缓存清理模块会定时检查本地硬盘缓存目录容量情况，如果容量已经达到阈值了，则进行文件的清理工作。 另外，异常 另外，异常管理模块处理客户端挂掉后的文件重新上传问题。 主要数据结构定义 class DiskCacheManagerImpl : public DiskCacheManager{ public: DiskCacheManagerImpl(); virtual ~DiskCacheManagerImpl() { TrimStop(); } int Init(const

client端数据结构 metaserver.proto space相关数据结构和proto 关键流程 init流程 write流程 read流程 整体架构 S3ClientAdaptor模块：负责将文件数据进行chunk，以及block的拆分为s3的object，并写入/读取s3的object。 S3-allocator模块：负责分配s3-object唯一标识。© XXX Page 3 of 11 文件首先会按照chunk进行拆分，每个chunk固定64M/1G（待定），chunk内部会划分为多个block，每个block最大4M，每个block对应s3上一个object。 s3上对象已chunkid_indexblock_version进行命名，元数据则已S3ChunkInfo（见数据结构）的方式存储在inode中。对于文件顺序写场景，文件0~4M的s3对象必然为chunkid_0_0 必然为chunkid_0_0,4M~8M为chunkid_1_0，以此类推， 还有一种情况是文件先写了0~2M，然后在写2M~4M，这里会采用append到同一个对象的方式进行写，而不是额外upload到一个新的对象；元数据则为{2,0,0,8M}。对于覆盖写，为了区分新老数据，则会对version进 行++，比如覆盖写了0~4M，则数据会写到chunkid_0_1的对象，则元数据包含了2个S3Chunkinfo{2

李小翠、吴汉卿、许超杰等 补充文件空间分配，讨论与确认 背景 调研 开源fs 性能对比 可行性分析 方案对比 对比结论 架构设计 卷和文件系统 元数据架构 文件系统快照 方案一：文件/目录级别快照 方案二：文件系统快照 关键点 元数据设计 数据结构 索引设计 文件空间管理 开发计划及安排 背景 为更好的支持云原生的场景，Curve需要支持高性能通用文件系统，其中高性能主要是适配 云原生数据库的场景。当前Curve是实现了块存储，向上提供块设备服务，CurveFS会基于此实现。第一阶段的目标是实现 满足数据库场景的文件接口。 调研 开源fs 当前对已有的开源分布式文件系统进行了调研，主要包括系统架构，元数据内存结构，元数据持久化，调研文档如下： chubaofs: ChubaoFS© XXX Page 3 of 14 1. 2. 3. moosefs: com/team/km_curve/article/29140 cephfs: https://kms.netease.com/team/km_curve/article/27909 性能对比 并对以上文件系统在相同环境进行了元数据节点性能测试： 。测试结果c开发的moosefs和fastcfs元数据性能远优于go开发的chubaofs和c开发的cephfs，理论上分析这个结果是合理的，分布式的元数据设

问题1：root用户无法访问挂载目录 测试 allow_root 测试allow_other 参考文献 问题2：本地文件系统挂载默认是共享的？ 问题3：文件系统访问控制是在哪一层实现的？ 二、文件系统权限管理 文件类型 文件权限 特殊权限(SUID, SGID, STICKY) 文件默认权限umask 用户&用户组 文件系统用户权限管理 对mode的管理 对ACL（Access Control Lists）的管理 Access Entry保存在哪？ ACL的表示 内存中的ACL 是如何与具体的 Inode 相关联 如何存储和获取ACL信息 Inode权限校验 chmod、chown、setfacl、getfacl接口文件系统自己如何实现 结论： 参考文献： 一、Curvefs测试 代码：https://github.com/cw123/curve/tree/fs_s3_joint_debugging 环境：test2 XXX Page 4 of 33 查阅资料发现这是fuse的一种安全策略，默认是只有filesystem owner拥有该文件系统的访问权限，如果想要其他用户有权访问，需要在挂载参数中指定‘-o allow-root’ 或'-o allow-other'以允许相应用户有权访问该文件系统，如果挂载者不是root还需要在/etc/fuse.conf（/usr/local/etc/fuse.conf）中增

size); open系统调用会打开pathname指定的文件（如果不存在，如果携带O_CREAT flag则会创建），返回一个文件描述符fd（该fd是进程打开文件描述符表的index），在后续系统调用（read(2)、write(2)、lseek(2)、fcntl(2) etc.）中指向这个打开的文件。打开的文件描述符记录中保存着文件的offset 和 文件status。 每个进程都有个 task_struct task_struct 描述符用来描述进程相关的信息，其中有个 files_struct 类型的 files 字段，里面有个保存了当前进程所有已打开文件 描述符的数组，而通过 fd 就可以找到具体的文件描述符:© XXX Page 3 of 23 open & openat 系统调用的区别：如果pathname是绝对路径，则dirfd参数没用。如果pathname是相对路径，并且dirfd的值不是AT_FDC V的早期版本引入的，后改进为O_NONBLOCK) flags中必须access mode：O_RDONLY, O_WRONLY, O_RDWR其中之一；© XXX Page 4 of 23 文件创建标志只影响打开操作, 文件状态标志影响后面的读写操作 file creation flags: O_CLOEXEC, O_CREAT, O_DIRECTORY, O_EXCL, O_NOCTTY, O_NOFOLLOW