curve块存储的topo信息由PhysicalPool、LogicalPool、Zone、Server、ChunkServer、CopySetInfo组成。curvefs可以照搬curve块存储的topo设计，只是保存的内容从数据变成了元数据。 curvefs的topo信息设计可以由PhysicalPool、LogicalPool、Zone、Server、MetaServer、CopySetInfo组成。 c 片将会占用最多的空间。这里忽略掉其他次要的因素，考虑全是空间碎片信息，每条记录只保存4KB数据，可以保存多少元数据。 选取占用空间更多的S3ChunkInfo。按照一台metaserver 256GB内存容量全部用来保存空间分配计算。可以的保存chunkinfo 条数 = 256GB / 64B = 4G。可以保存的文件的大小为4G * 4KB = 64TB的空间。 inode和dentry inode和dentry按照1:1估算，dentry按照name使用最大字节，选择占用空间更多的s3来计算。 文件大小 dentry大小 inode大小 可以保存inode和dentry数 1MB 312B 208B + (1MB / 4KB) * 64B = 16,592B 16261116 10MB 312B 208B + (10MB / 4KB) * 64B = 164,048B 1672413 100MB

te(2)、lseek(2)、fcntl(2) etc.）中指向这个打开的文件。打开的文件描述符记录中保存着文件的offset 和 文件status。 每个进程都有个 task_struct 描述符用来描述进程相关的信息，其中有个 files_struct 类型的 files 字段，里面有个保存了当前进程所有已打开文件 描述符的数组，而通过 fd 就可以找到具体的文件描述符:© XXX Page strace ./main open("in.txt", O_RDONLY|O_PATH) = 3 open flags 实现方式 cephfs处理方式是用Fh的结构体保存文件打开的状态和上下文信息，并不该Fh保存在Inode中，在后续读写等操作中依据该状态进行处理。 // cephfs Inode Fh.flags(cephfsFh struct Inode : RefCountedObject XXX Page 12 of 23 void get() { ++_ref; } int put() { return --_ref; } }; FastCFS处理方式是自定义FileInfo保存文件打开的状态信息，在create()、open()、opendir()操作时填充进 fuse_file_info结构中，在后续操作中直接使用： struct fuse_file_info { /**

(0XFF)，表示内容已结束 check_sum 8 保存校验和 (根据前 5 个部分内容计算得出) key_value_pairs 字段 字节数 说明 key_length 4 key 的长度 key $key_length 保存编码后的 key value_length 4 value 长度 value $value_length 保存编码后的 value© XXX Page 5 of 的高可用、高可扩方案？ 主要是 redis cluster + 主从复制 (或者第三方 codis + 哨兵) redis cluster/codis 主要解决扩展性的问题，它会进行分片，每个 redis 实例保存分片的 key 主从复制主要解决高可用，一个分片实例挂 2 个从实例，当主节点挂掉时，cluster/哨兵会自动将从节点升为主节点 redis + muliraft 存在的问题？ 每个 raft 比如说，要在字典里面查找一个键的话，程序会先在 ht[0] 里面进行查找，如果没找到的话，就会继续到 ht[1] 里面进行查找，诸如此类 另外, 在渐进式 rehash 执行期间, 新添加到字典的键值对一律会被保存到 ht[1] 里面, 而 ht[0] 则不再进行任何添加操作: 这一措施保证了 ht[0] 包含的键值对数量会只减不增, 并随着 rehash 操作的执行而最终变成空表© XXX Page 12 of

device)、iscsi • 支持RDMA和SPDK Curve块存储架构 • client：接受用户请求。 • mds：保存元数据，包括topo信息、块设备信息、 数据分布信息等，持久化到etcd中。 • chunkserver：采用raft协议3副本的方式保存块 设备上的数据。 • snapshotCloneServer：卷的快照克隆服务，持久 化到S3中。Curve块存储RAFT应用 client：接受用户请求，采用fuse的方式挂载挂载使用。 • 元数据集群：mds 和 metaserver。 • mds：保存元数据，包括topo信息、文件系统信 息、元数据分布信息等，持久化到etcd中。 • metaserver：采用raft协议3副本的方式保存文 件文件的元数据，包括inode，dentry，文件的 空间分配信息。 • 数据集群：采用外部存储，S3或者Curve块存储，保 响，利用操作系统的内存写时复制技术， fork一个进程创建完整的状态机的内存快照， 后台遍历内存，把内存的数据持久化到本地 磁盘 基于memory的存储引擎 • 存储元数据量不受内存大小限制 • raft apply请求，数据保存在rocksdb，向 rocksdb插入记录。 • raft snapshot，利用rocksdb的快照功能， 对rocksdb打快照。 • Curve文件系统也是使用copyset管理。 •

SGID, STICKY) 文件默认权限umask 用户&用户组 文件系统用户权限管理 对mode的管理 对ACL（Access Control Lists）的管理 ACL Access Entry保存在哪？ ACL的表示 内存中的ACL 是如何与具体的 Inode 相关联 如何存储和获取ACL信息 Inode权限校验 chmod、chown、setfacl、getfacl接口文件系统自己如何实现 #effective:rw-© XXX Page 26 of 33 group::r-x #effective:r-- mask::rw- other::r-- ACL Access Entry保存在哪？ ACL的表示 在Linux 中， ACL 是按照 Posix 标准来实现，其数据结构和 Posix 规定的 ACL 的数据是一致的。其定义在 include/linux/posix_acl *i_acl; struct posix_acl *i_default_acl; #endif ... } 如何存储和获取ACL信息 ACL 是物理文件系统的一个属性，需要永久保存。如何将 ACL 保存在外存中，包括 ACL 在外存中具体存放的位置，以及如何从外存中读取和写入原始 ACL 内容。涉及到 VFS 和具体的物理文件系统，这里以Ext4文件系统为例说明。© XXX Page 28

案： 第一种方案： Trash中只存放inode id， inode结构仍然在原地。由于inode放在原地， ，以便于扫描进程清理到期的inode。 那么需要实现类似freelist一样的东西来保存当前已经"被删"的inode id 由于inode放在原地，那么由于dentry已经被删除，那么查询工具就较为复杂，不能复用原有的client逻辑，需要组织成moosefs那样的meta文件系统可 Trash机制： metaserver端实现一个trash机制，需要做的事情如下： 以类似chubaofs的freelist的方式记录nlink==0的inode id， inode结构保存在原地，进入trash时记录进入trash的时间。 trash需要定期扫描freelist中的inode id， 当发现 大于7天（可配置）时，将inode清理，同时删除相关数据（s3上和卷上的）。 后台定期扫描清理 需要实现强制清理的接口； 为工具实现查询trash接口; Metaserver端功能二 session机制： 需要实现在metaserver open file的接口，在接口中保存session。（需不需要持久化？单节点metaserver可以不持久化，但是高可用之后，怎么通知另外两个metaserver，需要再考虑） 需要实现在metaserver close file的接口，移除session。

chunk raft 块设备的元数据管理 cephfs 3、各内存结构体 时间复杂度 空间复杂度 特点 可用实现 Btree 一个节点上保存多条数据，减少树的层次(4~5层)，方便从盘上读取数据，减少去盘上读取次数。适合在盘上和内存组织目录树。 google，https://github.com/abseil/abseil-cpp/tree/master/absl/c ee/， btree_map , btree_set, btree_multimap, and btree_multiset ，（ ） Apache B+tree 内部结点不保存数据，只有叶子结点保存数据。 https://github.com/begeekmyfriend/bplustree，（MIT），实现了落 盘 BST O(log(n)) O(n) c++ stl 模板©

write，read，delete和后台元数据整理以及数据回收流程 init流程 1.将conf中blockSize，chunkSize，metaServer和allocateServer ip保存在S3ClientAdaptor中 2.将conf中的S3相关信息：保罗ak，sk，s3address，bucketname等透传给S3Adapter模块。这里要注意，S3Adapter为原来cu 进行处理，分别获取要读取的每个S3ChunkInfo的offset len，封装到request中，具体可见代码的处理逻辑。 4.根据request进一步获取到s3 object去读取对象，将结果保存在response中。 5.最后根据所有的response将buff整合，返回给上层

3. 1. 1. 2. 3. metaserver: 元数据服务进程。一个进程管理多个复制组 copyset: 复制组，使用 raft 保证数据一致性。复制组中保存文件系统的部分元数据信息 文件系统元数据和复制组是多对多的关系 一个复制组可以包含多个文件的元数据信息 复制组 wal 记录元数据操作 定期 snapshot 对 wal 进行清理。snapshot → /B） 获取 /A 所在的 copyset /A 对应的dentry新增计数 创建 /B 节点 删除 /A 节点 Symlink 创建新的inode节点，dentry中标明符号链接 实际数据保存链接到的路径 Link 创建新的dentry, 指向同一个inode 文件系统快照 方案一：文件/目录级别快照 快照是文件系统或卷的只读副本，快照要求可以即时创建。类似 moosefs，curvefs

当缓存文件内容达到阈值时，停止向本地缓存盘写入。 同时，缓存清理模块会定时检查本地硬盘缓存目录容量情况，如果容量已经达到阈值了，则进行文件的清理工作。 本地缓存盘的异步上传 工作队列: 该队列中保存缓存盘中的待上传文件名 工作线程: 遍历工作队列(队列swap)，从缓存盘目录读取到文件内容并上传到对象存储。文件上传到对象存储后，直接删除。 工作队列做好互斥管理 异常管理 如果客户端挂掉