© 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的打开情况？ 正的执行删除inode。 目录的nlink字段与文件的nlink字段不同， ， 并且在目录下， ， 删除目录nlink相应的减1。 目录的nlink字段初始值为2 每创建一个新目录，nlink字段也会+1 目录不支持硬链接。 二是删除时lookup count未考虑： lookup count 指的是文件的访问计数。当文件/目录被打开时， ，该文件/目录仍然可以被打开的进程访问，不会 造成崩溃或报错，我们的curvefs也需要实现 即使文件/目录已经被另一个进程删除了（nlink==0） 这样的语义。 这部分内容在fuse的相关接口中也有描述如下： /** * Forget about an inode * * This function is called when the kernel removes an inode * from its internal

github代码仓库： https://github.com/opencurve/curve 概述背景 01 02 03 04 总体设计 系统特性 近期规划背景 • 多个存储软件：SDFS、NEFS、NBS • 已有的开源软件：Ceph • 不能胜任性能、延迟敏感的场景 • 异常场景抖动较大（比如慢盘场景） • 去中心节点设计在集群不均衡的情况下需要人工运维 • 基于通用分布式存储构建上层存储服务背景 1 • 采用append的方式写入数据组织形式 • AppendFile • 地址空间到—>chunk: 1 : 1 • 采用append的方式写入 • 支撑多副本对象存储 通过文件/特殊目录隔离 挖洞即时回收 单独的元信息的存储方案数据组织形式 • AppendECFile • 地址空间到—>chunk: 1 : 1 • 数据chunk + 校验chunk数据组织形式 • AppendECFile • 数据chunk + 校验chunk • 支撑EC存储场景 多个单副本的 chunk 形成 EC 组 一个对象作为 EC 组的一个满条带 挖洞即时空间回收拓扑 • 管理和组织机器 • 软件单元：chunkserver • 物理机：server • 故障域：zone • 物理池：poolIO流程 client MDS leader Chunk server 1、发起请求

XXX Page 1 of 33 CurveFs 用户权限系统调研（已实现）© XXX Page 2 of 33 一、Curvefs测试 1. 启动curvefs 问题1：root用户无法访问挂载目录 测试 allow_root 测试allow_other 参考文献 问题2：本地文件系统挂载默认是共享的？ 问题3：文件系统访问控制是在哪一层实现的？ 二、文件系统权限管理 文件类型 文件权限 启动curvefs 手动创建curve卷，/etc/curve/client.conf中配置卷所在集群信息。 启动服务&client挂载卷：bash startfs.sh start volume (挂载目录为/tmp/fsmount)© XXX Page 3 of 33 # wanghai01@pubbeta1-nostest2:~/curvefs/curve$ ps -ef | grep curvefs conf=./curvefs/conf/curvefs_client.conf /tmp/fsmount 问题1：root用户无法访问挂载目录 测试发现client mount进程是哪个用户启动的就只有该用户(filesystem owner)可以访问该目录，即使挂载点mode是777。 # filesystem owner wanghai01@pubbeta1-nostest2:/tmp$ ls

存，那么则尝试先写入本地硬盘写缓存目录。 写本地硬盘缓存目录之前先判断缓存目录容量是否已达到阈值，如果已经达到阈值，那么则直接写入到远端对象存储；否则，则写入到本地硬盘写缓存目录中。文件写入本地硬盘写缓存目录后，从本地硬盘读目录© XXX Page 4 of 9 做一个硬链接链接到该文件。 本次io在本地硬盘写入好之后，异步上传模块会适时把本地硬盘写缓存目录中的文件上传到远端对象存储集群，上 传成功后，删除本地写缓存目录中的对应文件。 同时，缓存清理模块会定时检查本地硬盘缓存目录容量情况，如果容量已经达到阈值了，则进行文件的清理工作。 另外，异常管理模块处理客户端挂掉后的文件重新上传问题。 主要数据结构定义 class DiskCacheManagerImpl : public DiskCacheManager{ public: DiskCacheManagerImpl(); 形式来表现。 配置一个目录用于本地硬盘的文件管理，对作为缓存盘的本地硬盘进行格式化并挂载到该目录(如果没有缓存盘，那一般而言就是系统盘本身了)。 本地缓存盘的文件内容表示 本地缓存盘存放的文件即是存储到对象存储中的对象。 写缓存如何作为读缓存利用 除了写缓存目录，另外引入读缓存目录；当写缓存目录中有新文件加入时，则对该文件做硬链接到读缓存目录。 这样，写缓存目录中的文件上传完之后就可以

2021-04-19 李小翠、吴汉卿、许超杰等 补充文件空间分配，讨论与确认 背景 调研 开源fs 性能对比 可行性分析 方案对比 对比结论 架构设计 卷和文件系统 元数据架构 文件系统快照 方案一：文件/目录级别快照 方案二：文件系统快照 关键点 元数据设计 数据结构 索引设计 文件空间管理 开发计划及安排 背景 为更好的支持云原生的场景，Curve需要支持高性能通用文件系统，其中高性能主要 能？ 可行性分析 方案对比 根据上述调研和测试结果，我们考虑了三种curvefs的元数据设计方案： CurveFS kv方案设计 curve实现块设备时，元数据不是扁平化的设计，而是采用来有目录层级的 namespace 方式，namespace 已经实现了 fs 元数据管理的雏形，具备了基本的元数据管理功能。（当时为什么要设计为 namespace 的管理形式？留有租户这个概念），直接基于 文件系统中文件数据和chunk是一对多的关系。 底层 chunk 固定大小，一个 chunk 可以分为多个固定大小的 extent 大文件可以包含多个 chunk， 小文件可以共用 chunk 文件的目录数结构有单独的元数据节点存储 元数据包含两层映射，dentry，inode inode 在每个文件系统中是全局唯一的，inode 中包含文件的信息，包括用户，时间，软/硬链，数据分布等 元数据架构

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按照inodeid进行分片，Dentry按照parentid进行分片 fastcfs 有元数据服务器 inode和dentry放一个结构体。 inode → hashtable（key是ino，全局） dentry → skip list （key是name，每个目录下一个） 计算出来的 binlog，随时间会越来越大 差 DG Master/Slave glusterfs 无中心化服务器 dht算法 hash 扩展时大量迁移 client缓存 3、各内存结构体 时间复杂度 空间复杂度 特点 可用实现 Btree 一个节点上保存多条数据，减少树的层次(4~5层)，方便从盘上读取数据，减少去盘上读取次数。适合在盘上和内存组织目录树。 google，https://github.com/abseil/abseil-cpp/tree/master/absl/c ontainer 实现了btree map和btree set，(Apache)。

com/opencurve/curve Curve 3/33为用户服务 作为一个复杂的大型分布式存储系统，Curve 需要利用科学的方法论和专业的工具，在整个 软件生命周期内更好地为用户服务：  质量——向用户交付稳定可靠的软件；  监控——直观地展示Curve运行状态；  运维——保障Curve始终稳定高效运行。 质量 ✓ 质量管理体系（设计、开发、review、CI） ✓ （易部署、易升级、自治） ✓ 运维工具（部署工具、管理工具） 4/33背景 01 02 03 04 Curve质量控制 Curve监控体系 Curve运维体系软件质量 软件质量的定义是：软件与明确地和隐含地定义的需求相一致的程度。 为了确保最终交付的软件满足需求，必须将质量控制贯穿于设计、开发到测试的整个流程中。 设计  设计流程  文档规范 开发  编码规范与提交流程  版本管理 20轮自动化随机故障注入 12/33单元测试 单元测试是软件开发的过程中最基本的测试，它用来对一个模块、一个函数或者一个类来进行 正确性检验的测试工作。 curve通过lcov统计代码覆盖率，衡量单元测试的完备程度，如下图所示： 13/33集成测试 测试目的 测试内容 单元测试后，有必要进行集成测试，发现 并排除在模块连接中可能发生的上述问题， 最终构成要求的软件子系统或系统。集成 测试需要关注的主要是各模块连接起来后

irfd参数没用。如果pathname是相对路径，并且dirfd的值不是AT_FDCWD，则pathname的参照物是相对于dirfd指向的目录，而不是进程的当前工作目录；反之，如 果dirfd的值是AT_FDCWD，pathname则是相对于进程当前工作目录的相对路径，此时等同于open。 open flags flags定义 flags通过宏定义实现，定义见 ，主要包括如下flag fcntl flags的含义 O_RDONLY: 只读 : 只写 O_WRONLY : 读写 O_RDWR O_CREAT: 当pathname对应的文件不存在时则创建它，文件uid为进程uid，gid为进程gid或父目录gid（取决于SGID是否置位）；当flags中出现O_CREAT 或 O_TMPFILE时，mode参数必须提供，否则会使用栈中随机字节填充；通常在没有ACL的情况下，有效的mode是经过与进程mask作用后的结果（mode 用户空间直接将数据传递到文件或磁盘设备。 O_DIRECT : 使得32位操作系统对大文件支持（_FILE_OFFSET_BITS=64）。 O_LARGEFILE : 以目录形式打开，如果pathname不是一个目录则会打开失败。 O_DIRECTORY : 。 O_NOFOLLOW 如果pathname是一个符号链接，则会打开失败（ELOOP） : 不更新Inode中的last access

id获取parent inode 所在copyset，metaserver ip等信息 ，然后从metaserver获取denty（这里有两种方式，一种是只获取当前需要的 denty，一种是list整个目录的denty，这个需要考虑用哪个接口） 根据找到的denty结构，获取inodeid，设置 fuse_entry_param，返回给fuse write void (*write) (fuse_req_t O_TRUNC 如果文件存在，且为只写或只读打开，则将其文件长度截短为0 O_DSYNC sync数据和必要元数据（不影响读取刚写入的数据） O_SYNC sync数据和所有元数据 O_DIRECTORY 目录 O_DIRECT 直接IO open的主要逻辑： 根据inode id，从mds获取inode所在copyset，metaserver ip等信息，然后从metaserver获取inode结构，缓存之； const char *name); 根据parent inode id 和 name找到当前文件的inode和denty结构 根据lookup count 值，如果非0，则需要延迟删除目录，如果为0，则删除目录。 删除时需要从缓存或mds查询删除inode和dentry的位置，并去metaserver删除，然后清除本地缓存 opendir 可先不支持，返回ENOSYS readdir

chunk的关系如下图:NAMESERVER Namespace的文件的目录层次关系如右图。 文件的元数据以KV的方式存储。 • Key：ParentID + “/”+ BaseName； • Value：自身的文件ID。 这种方式可以很好地平衡几个需求： • 文件列目录：列出目录下的所有文件和目 录 • 文件查找：查找一个具体的文件 • 目录重命名：对一个目录/文件进行重命名 当前元数据信息编码之后存储在 etcd