CurveFS kv方案设计 curve实现块设备时，元数据不是扁平化的设计，而是采用来有目录层级的 namespace 方式，namespace 已经实现了 fs 元数据管理的雏形，具备了基本的元数据管理功能。（当时为什么要设计为 namespace 的管理形式？留有租户这个概念），直接基于 namespace 开发： a. 功能 软/硬链接：目前是都不支持的。软链接可以通过标识文件类型解决；由于

pool1 type: 0 replicasnum: 3 copysetnum: 100 zonenum: 3 scatterwidth: 0NAMESERVER NameServer管理namespace元数据信息，包括（更具体的信息可以查看curve/proto/nameserver2.proto）： • FileInfo: 文件的信息。 • PageFileSegment: segment是给文件分配空间的最小单位 segment是给文件分配空间的最小单位 。 • PageFileChunkInfo: chunk是数据分片的最小单元。 segment 和 chunk的关系如下图:NAMESERVER Namespace的文件的目录层次关系如右图。 文件的元数据以KV的方式存储。 • Key：ParentID + “/”+ BaseName； • Value：自身的文件ID。 这种方式可以很好地平衡几个需求： •

如果pathname是一个符号链接，则会打开失败（ELOOP） : 不更新Inode中的last access time（进程uid=文件uid或者进程在它的user namespace有CAP_FOWNER, 而文件的uid在这个namespace中有一个映射）。 O_NOATIME : 在进程执行exec系统调用时关闭此打开的文件描述符，防止父进程泄露打开的文件给子进程。 O_CLOEXEC O_PATH:

元数据持久化在单独的元数据服务器上？在磁盘上？在volume上？ inode+dentry方式？当前curve块存储的kv方式？ 是否有单独的元数据管理服务器？ 2、其他文件系统的调研总结 fs 中心化元数据 内存namespace元数据 内存空间分配元数据 元数据持久化 元数据扩展 小文件优化 空间管理单位 数据持久化 其他© XXX Page 3 of 24 moosefs（mfs） 有元数据服务器 全内存 fsnode