1、背景 • 2、chubaofs的元数据管理 • 2.1、meta partition的创建 • 2.2、meta partition的管理 • 2.3、meta partition和inode以及dentry的对应关系? • 3、curvefs的copyset和fs的对应关系 • 3.1 如何获取inodeid • 3.2 copyset fs共用吗? • 3.3 copyset个数是否可以动态调整 metaserver 子模块拆分 8、inode和dentry的内存估算 - 8.1 一台机器上能存放多少个inode和dentry - 8.2 一台机器上建议的copyset数量 - 8.3 每个copyset建议管理存储容量的大小 ## 1、 背景 curvefs使用raft作为元数据一致性的保证。为了提高元数据的可扩展性和并发处理能力，采用元数据分片的方式管理inode和dentry的元数据。inode的分片依据是fsid 。inode的分片依据是fsid + inodeid，dentry的分片依据是fsid + parentinodeid。借鉴curve块设备的设计思路，（补充copyset的设计文档在这），curvefs的元数据分片仍然按照的copyset的方式去管理。 curve块存储的topo信息由PhysicalPool、LogicalPool、Zone、Server、ChunkServer、CopySe

中的基本类型 • Object 一切对象的公共基类。 • INode 一切节点的公共基类。 [X]zeno/ [X]zeno/ back/ core/ defNode.h Descriptor.cpp Descriptor.h Graph.cpp Graph.h INode.cpp INode.h IObject.cpp IObject {“PrimitiveCreate”, “prim”} 就表示这个端口连接了 PrimitiveCreate 节点的 prim 输出端口。 • ( zany 是 shared_ptr 的缩写) struct INode { public: Graph *graph = nullptr; INodeClass *nodeClass = nullptr; }; std::string myname; ZENO_API INode(); ZENO_API virtual ~INode(); //INode(INode const &) = delete; //INode &operator=(INode const &) = delete; //INode(INode &&) = delete; //INode &operator=(INode &&)

是否需要做 session 机制（在 metaserver 打开），来维护 inode 的打开情况？ • 方案设计 • Trash机制： • Session机制： • 遗留问题 • 工作量评估 ## 背景 目前curvefs client版本对删除unlink和rmdir的设计只有简单的删除inode和dentry结构，遗留了nlink和lookup count相关的内容 << ", name = " << name; return ret; } // TODO(xuchaojie) : judge can inode be deleted ret = inodeManager_-->DeleteNode(dentry.inodeid()); if (ret != CURVEFS_ERROR::OK) { " << parent << ", name = " << name << ", inode = " << dentry.inodeid(); return ret; } return ret; ## 存在两个问题： 一是删除时nlink字段未考虑： 文件的nlink用于实现hard

word_language_model • LOOKUP inode 返回 fstat + timeout 设置 • OPEN 打开 inode 返回 ok • GETATTR 返回fstat - READ inode 读取的内容不等从16KB到128KB - 关闭文件时会发送FLUSH请求和RELEASE请求 - 场景2 解压压缩包场景 • LOOKUP inode 没有该inode • CREATE创建文件句柄并返回fstat CREATE创建文件句柄并返回fstat + timeout设置 • WRITE 写入内容从0～16KB不等 SETATTR inode 根据UID，ETIME，CTIME，length来设置属性 - 关闭文件时会发送FLUSH请求和RELEASE请求  |ext4|64us|96us|37us| |FUSE|156us|560us|118us| |用户态的系统调用劫持|87us|312us|219us| ## 基于FUSE的优化框架 • 框架优化的要点 • 共享inode cache - 共享data cache的映射 GETATTR流程 • 文件读取流程 - 相关工作 • extFUSE • google android12 passthrough

Curve文件系统元数据管理（已实现） Inode 1、设计一个分布式文件系统需要考虑的点： • 2、其他文件系统的调研总结 • 3、各内存结构体 • 4、curve文件系统的元数据内存组织 • 4.1 inode定义： • 4.2 dentry的定义： • 4.3 内存组织 5元数据分片 • 5.1 分片方式一：inode和dentry都按照parentid分片 5.1 link: - hardlink: 生成一个hardlink /B/E，指向文件/A/C - list: 遍历/A目录 5.1.2 好处 5.1.2 问题 • 5.2 分片方式二：Inode按照inodeid进行分片，Dentry按照parentid进行分片 - rename: rename /A/C到/B/E - hardlink: 生成一个hardlink /B/E，指向文件/A/C 6、curve文件系统的多文件系统的设计 ## 1、 设计一个分布式文件系统需要考虑的点： 1. 文件系统的元数据是否全缓存？ 2. 元数据持久化在单独的元数据服务器上？在磁盘上？在volume上？ 3. inode+dentry方式？当前curve块存储的kv方式？ 4. 是否有单独的元数据管理服务器？ ## 2、 其他文件系统的调研总结 |fs|中心化元数据|内存 namespace 元数据|内存

数据整理作为一个后台服务(线程池)，运行于metaserver，遍历metaserver的inode进行数据整理的尝试，入队inodekey，如果是已有inode任务，enqueue直接返回，不入队 2. 任务开始执行，尝试根据inodekey获取inode信息，获取不到就退出；不是s3类型的inode退出 3. 对于每一个s3类型的inode来说，对每一个index内的chunkinfo按照chunkid升序排序 加锁，增量的更新inode的s3chunkinfolist，保证原子更新，更新失败回退新增数据 - 等待N秒，保证mds已经告知client缓存失效，需要更新为新的s3chunkinfolist // 需不需要这个步骤@xuchaojie@chenwei确认 ## 问题与风险 1. 在执行变更时，在bcd步挂掉时，会造成s3数据的残留 2. 当同时有多个变更inode元数据(s3chu nkinfolist)的动作时，目前的updateinode的实现是直接的覆盖，如果数据整理和client写同时进行了同一个inode的变更，总有一个变更会丢失， ## 需要进行一个merge的步骤 ## 在做变更时如果有其他op可能会产生的冲突： 读：在执行变更删除原来的s3 object时，执行读的客户端的缓存可能还是原有的chunkinfolist，可能会去读已经删除的object，这种时候读会失败

(void *userdata, struct fuse_conn_info *conn); 根据挂载信息，从mds获取文件系统信息（或superblock），块分配器（ bitmap ）和root inode所在的copyset、metaserver ip等信息 ■ 去metaserver获取文件系统信息（super block），缓存到client端。 ## destroy void (*destroy) req, fuse_ino_t parent, const char *name); 根据parent inode id和name从denty缓存中找到对应的denty结构： - 如果denty缓存中不存在对应的inode，则从mds根据parent inode id获取parent inode所在copyset，metaserver ip等信息，然后从metaserver获取denty（这里有两 struct fuse file info *fi); ■ 首先根据inode id 从缓存中查找到对应inode结构； ■ 如果inode缓存中不存在对应的inode，则从mds获取inode所在copyset，metaserver ip等信息，然后从metaserver获取inode结构，缓存之； 判断inode结构中，对应请求[off, size]位置的空间是否有分配：如果未分配或只

扩展性/可用性/可靠性 依赖于第三方kv存储，目前是etcd ### 2. CurveFS 单机内存元数据设计 类似 fastcfs 和 moosefs 的元数据设计方式，采用通用的 dentry，inode 两层映射关系，所有的元数据都缓存在内存中，持久化在 binlog 文件中，binlog 采用定期 dump 的方式删除。基于这种方式的开发： a. 性能 加载：数据量较大的情况下，元数据节点启动较慢；但是元数据使用 在内存中也缓存了全部元数据信息 master-slave 多副本数据 ### 3. CurveFS 分布式元数据设计 类似 chubaofs 的元数据设计方式，同样是采用 dentry，inode 两层映射关系，所有的元数据都缓存在内存中。元数据是分片的，使用 multi-raft 持久化元数据以及保证多副本数据一致性。基于这种方式开发： ### a. 性能 由于元数据分片，获取元数据 近期要能支持 mysql 所要接口，长期需要支持通用文件接口。 kv 虽然改造简单，短期内对基本功能的支持没有问题，但这个架构不利于 Curve 长期的规划和演进，因此选择通用的 dentry，inode 两层映射的元数据结构。对于 fs 的场景，元数据的量比块存储场景会多很多，长期看元数据节点的设计也是需要满足高可用、高可扩、高可靠的。 因此对元数据节点的要求总结为：高可用、高可扩、高可靠、高性能。

对ACL（Access Control Lists）的管理 - ACL Access Entry保存在哪? • ACL的表示 • 内存中的ACL 是如何与具体的 Inode 相关联 • 如何存储和获取ACL信息 • Inode权限校验 • chmod、chown、setfacl、getfacl接口文件系统自己如何实现 • 结论： • 参考文献： ## 一、 Curvefs测试 般用sudo管理提权 用户和用户组的关系：一对一、一对多、多对一、多对多 ## 文件系统用户权限管理 ## 对mode的管理 uidgidmode message Inode { required uint64 号id = 1; required uint32 fsId = 2; required uint64 length = 3; required number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink

这个思路上该缓存方案主要针对的场景是顺序写和顺序读，而对于随机写和随机读来说也会有一定性能提升，但效果可能不会太好。 ## 元数据采用2层索引 由于chunk大小是固定的（默认64M），所以Inode中采用map s3ChunkInfoMap用于保存对象存储的位置信息。采用2级索引的好处是，根据操作的offset可以快速定位到index 介绍这些接口流程。这里不需要提供truncate接口，可以由client直接修改inode的len，由metaserver的碎片整理（马杰负责）模块进行truncate的无效数据清理 ## 后台刷数据线程 启动后台线程，将写Cache定时刷到S3上，同时通过inodeManager更新inode缓存中的s3InfoList。具体细节见 ## 本地磁盘缓存 如果有配置writeBack 4; // file logic length required uint64 size = 5; // file size in object storage }; message Inode { required uint64 inodeId = 1; required uint32 fsId = 2; required uint64 length = 3;