• 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个数是否可以动态调整 子模块拆分 8、inode和dentry的内存估算 - 8.1 一台机器上能存放多少个inode和dentry - 8.2 一台机器上建议的copyset数量 - 8.3 每个copyset建议管理存储容量的大小 ## 1、 背景 curvefs使用raft作为元数据一致性的保证。为了提高元数据的可扩展性和并发处理能力，采用元数据分片的方式管理inode和dentry的元数据。inode的分片依据是fsid 的分片依据是fsid + inodeid，dentry的分片依据是fsid + parentinodeid。借鉴curve块设备的设计思路，（补充copyset的设计文档在这），curvefs的元数据分片仍然按照的copyset的方式去管理。 curve块存储的topo信息由PhysicalPool、LogicalPool、Zone、Server、ChunkServer、CopySetInfo组

2、其他文件系统的调研总结 • 3、各内存结构体 • 4、curve文件系统的元数据内存组织 • 4.1 inode定义： • 4.2 dentry的定义： • 4.3 内存组织 5元数据分片 • 5.1 分片方式一：inode和dentry都按照parentid分片 5.1.1 场景分析 查找：查找/A/C。 - 创建：/A/C不在，创建/A/C - 删除文件：删除/A/C 生成一个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文件系统的多文件系统的设计 6、curve文件系统的多文件系统的设计 ## 1、 设计一个分布式文件系统需要考虑的点： 1. 文件系统的元数据是否全缓存？ 2. 元数据持久化在单独的元数据服务器上？在磁盘上？在volume上？ 3. inode+dentry方式？当前curve块存储的kv方式？ 4. 是否有单独的元数据管理服务器？ ## 2、 其他文件系统的调研总结 |fs|中心化元数据|内存 namespace 元数据|内存空间分配元数

当 2 个操作的 dentry 属于同一个 copyset 有什么不一样？ ## 背景 当前 curvefs 并没有实现 rename 接口，本文档是对 rename 接口实现的调研及方案设计。 rename 操作，主要操作的是 dentry，如 rename /dir1/file1 /dir2/file2，主要有 2 个步骤：（1）删除 file1 的 dentry，（2）增加 file2 file2 的 dentry（该 dentry 的 inodeid 等同 file1 的 inode id）。关于 rename 接口的实现，主要调研了 chubaofs 和 juicefs，而 rename 的实现难点主要在于其原子性的保证。 ## 方案调研 ## Chubaofs chubaofs 中的 rename 实现不是原子性的，它是通用创建源文件的硬连接，然后删除源文件的方式来实现的，主要有以下 要有以下 4 步： 1. 将源文件的 nlink 加一 2. 创建目标文件的 dentry 3. 删除源文件的 dentry 4. 将源文件的 nlink 减一 而每一步骤都有可能出错，chubaofs 针对以上的 4 步骤中出现的错误处理如下： 1. 步骤 1 出错，啥事都没发生 2. 步骤 2 出错，等同于创建硬连接出错，恢复机制如下： 1. 将源文件的 nlink

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

和name，向mds查询创建dentry和inode的位置，去meta server创建dentry和inode ■ 预分配一些空间？可先不做 ## mkdir void (*mkdir) (fuse_req_t req, fuse_ino_t parent, const char *name, mode_t mode); 根据parent inode id 和name，向mds查询创建dentry和inode的位置，去meta e的位置，去meta server创建dentry和inode ## forget void (*forget) (fuse req t req, fuse ino t ino, uint64_t nlookup); 根据inode找到对应的inode结构，lookup count值减少nlookup。（这里涉及到一个lookup count 存在哪里的问题） ## unlink void name找到当前文件的inode和denty结构 根据lookup count 值，如果非0，则需要延迟删除文件，如果为0，则真正删除文件。（这里需要做标记删除） 删除时需要从缓存或mds查询删除inode和dentry的位置，并去metaserver删除，然后清除本地缓存 ## rmdir void (*rmdir) (fuse req_t req, fuse_ino_t parent, const

Trash机制： • Session机制： • 遗留问题 • 工作量评估 ## 背景 目前curvefs client版本对删除unlink和rmdir的设计只有简单的删除inode和dentry结构，遗留了nlink和lookup count相关的内容还未实现，是不完备的。本文首先调研moosefs，chubaofs等分布式系统，参考并设计解决上述遗留问题。 当前删除接口代码如下： CURVEFS_ERROR fuse_req_t req, fuse_ino_t parent, const char *name) { Dentry dentry; CURVEFS_ERROR ret = dentryManager_->GetDentry(parent, name, &dentry) if (ret != CURVEFS_ERROR::OK) { LOG(ERROR) << return ret; } // TODO(xuchaojie) : judge can inode be deleted ret = inodeManager_-->DeleteNode(dentry.inodeid()); if (ret != CURVEFS_ERROR::OK) { LOG(ERROR) << "inodeManager_DeleteNode

NOSPACE = 2; // } // dentry interface message GetDentryRequest { required uint32 fsId = 1; required uint64 parentInodeId = 2; required string name = 3; } message Dentry { required uint32 = 4; } message GetDentryResponse { required MetaStatusCode statusCode = 1; optional Dentry dentry = 2; } message ListDentryRequest { required uint32 fsId = 1; required uint64 dirInodeId ListDentryResponse { required MetaStatusCode statusCode = 1; repeated Dentry dentrys = 2; } message CreateDentryRequest { required Dentry dentry = 1; } message CreateDentryResponse { required MetaStatusCode

持久化文件中涉及到的数字均以小端序存储 - 利用 fork 子进程（COW）的方式解决在持久化的过程中，读写冲突的问题以及性能问题 ## 实现 ## 1、 inode、entry 的编码 - 给 inode、dentry 增加编码函数 // 这里要尽可能减少 key/value 编码后的字节数，这样同样的内存可以存入较多的 key/value 对 • 序列化目前主要考虑以下 2 种，一种是参考 chubaofs uint32 fsId = 1; required uint64 parentInodeId = 2; required string name = 3; } message Dentry { required uint32 fsId = 1; required uint64 inodeId = 2; required uint64 parentInodeId KVStore 将当前实现中的 MemoryDentryStorage 和 MemoryInodeStorage 抽象成一个 KVStore，对外提供 SET/GET/DEL 等接口，inode/dentry 均编码后以 key-value 的形式存入 KVStore 当前实现可先只实现 KVStore（提供方便 API），Raft 等可以后续接入（目前实现中持久化可以在 KVStore 退出时触发持久化，或定时持久化）

FDIREntryInfo dentry; }; int flags; int magic; struct { int last_modified_time; } write_notify; int64_t offset; //current offset } FCFSAPIFileInfo; static int do_open(fuse_req_t req, FDIREntryInfo *dentry,

entry (term, data ...) log entry (term, data ...) Term VoteFor Partition inode tree Partition dentry tree Partition status ## CurveFS Client ![Image](/uploads/documents/3/6/d/1/36d12a333823f1a2a2