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

Trash放在哪里？ 3. 是否需要做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_->DeleteInode(dentry.inodeid()); if (ret != CURVEFS_ERROR::OK) << ", parent = " << parent << ", name = " << name << ", inode = " << dentry.inodeid(); return ret; } return ret; } 存在两个问题: 一是删除时nlink字段未考虑： 文件的nlink用于实现hard

(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结构； 如果dentry缓存中不存在对应的inode，则从mds根据parent inode id获取parent inode 所在copyset，metaserver ip等信息 ，然后从metaserver获取denty（这里有两种方式，一种是只获取当前需要的 off, struct fuse_file_info *fi); 首先根据inode id 从缓存中查找到对应inode结构； 如果inode缓存中不存在对应的inode，则从mds获取inode所在copyset，metaserver ip等信息，然后从metaserver获取inode结构，缓存之； 判断inode结构中，对应请求[off, size]位置的空间是否有分配：如果未分配或只有部

陈威 增加详细设计 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 每个volume有若干meta partition和data partition。meta partition管理的元数据，data partition管理数据。meta partition管理inode和dentry信息。 创建一个文件系统时，如何初始化meta partition？ master\cluster.go， chubaofs的文件系统使用volume的来表示，在创建一个文件系统的时候，会创建3个meta

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

。从这个思路上该缓存方案主要针对的场景是顺序写和顺序 读，而对于随机写和随机读来说也会有一定性能提升，但效果可能不会太好。 元数据采用2层索引 由于chunk大小是固定的（默认64M），所以Inode中采用map s3ChunkInfoMap用于保存对象存储的位置信息。采用2级索引的好处是，根据操作的offset可以快速定位到index，则只需 些接口流程。这里不需要提供truncate接口，可以由client直接修改inode的len，由metaserver的碎片整 理（马杰负责）模块进行truncate的无效数据清理 后台刷数据线程© XXX Page 4 of 9 启动后台线程，将写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;

对mode的管理 对ACL（Access Control Lists）的管理 ACL Access Entry保存在哪？ ACL的表示 内存中的ACL 是如何与具体的 Inode 相关联 如何存储和获取ACL信息 Inode权限校验 chmod、chown、setfacl、getfacl接口文件系统自己如何实现 结论： 参考文献： 一、Curvefs测试 代码：https://github 具备系统管理员root的权限的运维人员添加的，权限很小，一般用sudo管理提权 用户和用户组的关系： 一对一、一对多、多对一、多对多 文件系统用户权限管理 对mode的管理 uidgidmode message Inode { required uint64 inodeId = 1; required uint32 fsId = 2; required uint64 length = 3; 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

以目录形式打开，如果pathname不是一个目录则会打开失败。 O_DIRECTORY : 。 O_NOFOLLOW 如果pathname是一个符号链接，则会打开失败（ELOOP） : 不更新Inode中的last access time（进程uid=文件uid或者进程在它的user namespace有CAP_FOWNER, 而文件的uid在这个namespace中有一个映射）。 O_NOATIME filesystem process. Valid replies: fuse_reply_open fuse_reply_err Parameters req request handle ino the inode number fi file information© XXX Page 7 of 23 open flags 在curvefs上的测试 在现在的curvefs上进行open相关flag测试，发现已经支持部分open strace ./main ... open("dir", O_RDONLY|O_DIRECTORY) = 3 curvefsO_NOFOLLOW # O_NOFOLLOW curvefs inode mtime/atime/ctimeO_NOATIME # O_NOATIME O_PATH root@pubbeta1-nostest2:/tmp/fsmount$ strace ./main

.2015/06/26 7.1 认识 Linux 文件系统 7.1.1 磁盘组成与分区的复习 7.1.2 文件系统特性： 索引式文件系统 7.1.3 Linux 的 EXT2 文件系统（inode）: data block, superblock,dumpe2fs 7.1.4 与目录树的关系 7.1.5 EXT2/EXT3 文件的存取与日志式文件系统的功能 7.1.6 Linux 文件系统的运行 2015/07/28 14.1 磁盘配额 （Quota） 的应用与实作 鸟哥的 Linux 私房菜：基础学习篇 第四版 22 目录及概述 14.1.1 什么是 Quota：一般用途, 限制, 规范 （inode/block, soft/hard, grace time） 14.1.2 一个 XFS 文件系统的 Quota 的实作范例 14.1.3 实作 Quota 流程-1：文件系统的支持与观察（/etc/fstab *:代表可可执行文件； /:代表目录； =:代表 socket 文件； |:代表 FIFO 文件； -h ：将文件大小以人类较易读的方式（例如 GB, KB 等等）列出来； -i ：列出 inode 号码，inode 的意义下一章将会介绍； -l ：长数据串行出，包含文件的属性与权限等等数据；（常用） -n ：列出 UID 与 GID 而非使用者与群组的名称 （UID与GID会在帐号管理提到！）

/:代表目录； =:代表 socket 文件； |:代表 FIFO 文件； 11. -h ：将文件大小以人类较易读的方式（例如 GB, KB 等等）列出来； 12. -i ：列出 inode 号码，inode 的意义下一章将会介绍； 13. -l ：长数据串行出，包含文件的属性与权限等等数据；（常用） 14. -n ：列出 UID 与 GID 而非使用者与群组的名称 （UID与GID会在帐号管理提到！） 太大会造成磁盘容量 的浪费，太小则会产生文件无法储存的困扰。此外，我们在前面几章谈到的文件权限与属性中， 这些权限与属性分别 记录在文件系统的哪个区块内？这就得要谈到 filesystem 中的 inode 与 block 了。同时，为了虚拟化与大容 量磁盘， 现在的 CentOS 7 默认使用大容量性能较佳的 xfs 当默认文件系统了！这也得了解一下。 在本章我们 的重点在于如何制作文件系统， EXT2 开始！ 而文件系统是创建在磁盘上面的，因此我们得了解磁盘的物理组成才行。磁盘物理组成的部分 我们在第零章谈过了，至于磁盘分区则在第二章谈过了，所以下面只会很快的复习这两部份。 重点在于 inode, block 还有 superblock 等文件系统的基本部分喔！ 由于各项磁盘的物理组成我们在第零章里面就介绍过， 同时第二章也谈过分区的概念了，所以这个小节我们就拿之前 的重点出来介绍就好了！