© 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 元数据分片 1、设计一个分布式文件系统需要考虑的点： 文件系统的元数据是否全缓存？ 元数据持久化在单独的元数据服务器上？在磁盘上？在volume上？ inode+dentry方式？当前curve块存储的kv方式？ 是否有单独的元数据管理服务器？ 2、其他文件系统的调研总结 fs 中心化元数据 内存namespace元数据 内存空间分配元数据 元数据持久化 元数据扩展 小文件优化 空间管理单位 数据持久化 其他© XXX + name) segment kv → hashtable(key inode + offset) etcd 差 块设备，最小10GB segment + chunk raft 块设备的元数据管理 cephfs 3、各内存结构体 时间复杂度 空间复杂度 特点 可用实现 Btree 一个节点上保存多条数据，减少树的层次(4~5层)

计方案： CurveFS kv方案设计 curve实现块设备时，元数据不是扁平化的设计，而是采用来有目录层级的 namespace 方式，namespace 已经实现了 fs 元数据管理的雏形，具备了基本的元数据管理功能。（当时为什么要设计为 namespace 的管理形式？留有租户这个概念），直接基于 namespace 开发： a. 功能 软/硬链接：目前是都不支持的。软链接可以通过标识文件类型解决；由于 中包含文件的信息，包括用户，时间，软/硬链，数据分布等 元数据架构 元数据包含两个部分 卷的元数据管理 这部分 mds 已经实现。在上面架了一层文件系统后，卷信息中还需要包含文件系统元数据的路由信息 文件系统的元数据管理 需要记录 dentry，inode 这两层元数据。包括内存结构和持久化结构 下面先介绍文件系统的元数据管理，再介绍卷的元数据管理的变化 元数据节点的架构如下© XXX Page 6 of 14 1 inode-inodeInfo; dentry 中存储 filename-dentryInfo 信息 copyset 启动的时候根据 inode 和 dentry 分别建立对应的内存结构，再回放 wal 日志完成构建 卷的元数据管理 卷的元数据中需要包含建立在该卷之上的文件系统元数据分片的位置，以便进行元数据的索引 常见的元数据操作 Create 与 mds 交互获取 inode 和 dentry 的 copyset

修改者 修改内容 1.0 2021/7/23 陈威 初稿 1.1 2021/8/4 陈威 根据评审意见修改 1.2 2021/8/9 陈威 增加详细设计 1、背景 2、chubaofs的元数据管理 2.1、meta partition的创建 2.2、meta partition的管理 2.3、meta partition和inode以及dentry的对应关系？ 3、curvefs的copyset和fs的对应关系 而是每次都需 要去metaserver上去进行分配。 这里需要重新考虑curvefs的copyset和fs的元数据分片的对应关系。© XXX Page 3 of 19 2、chubaofs的元数据管理 chubaofs（补充链接）的元数据也是采用的raft的方式进行管理，可以借鉴一下chubaofs的元数据的分片策略。 通过分析chubaofs的源代码。chubaofs的用volume管理 ，在创建完成之后，才有inodeid。inodeid的分配最好下放到各个分片去进行处理。否则整个集群的inode都去一个地方获取id会 造成巨大的锁开销，这个是不能接受的。 curve块设备的元数据管理，在分配数据的时候，offset一开始就是知道的，这是和curvefs分配很大的一个不同点。 假设已经确定了一个分片规则，那么根据这个分片规则，一定可以找到两个函数 inodeid到copyset的映射：copysetid

收集集群状态信息，自动调度 • 数据节点 Chunkserver 数据存储 副本一致性 • 客户端 Client 对元数据增删改查 对数据增删改查 • 快照克隆服务器MDS各个组件 MDS是中心节点，负责元数据管理、集群状态收集与调度。MDS包含以下几个部分： • Topology: 管理集群的 topo 元数据信息。 • Nameserver: 管理文件的元数据信息。 • Copyset: 副本放置策略。