1 of 11 Curve文件系统空间分配方案（基于块的方案，已实现）© XXX Page 2 of 11 背景 本地文件系统空间分配相关特性 局部性 延迟分配/Allocate-on-flush Inline file/data 空间分配 整体设计 空间分配流程 特殊情况 空间回收 小文件处理 并发问题 文件系统扩容 接口设计 RPC接口 空间分配器接口 背景 根据 ，文件系 ，文件系统基于当前的块进行实现，所以需要设计基于块的空间分配器，用于分配并存储文件数据。 CurveFS方案设计（总体设计，只实现了部分） 本地文件系统空间分配相关特性 局部性 尽量分配连续的磁盘空间，存储文件的数据。这一特性主要是针对HDD进行的优化，降低磁盘寻道时间。 延迟分配/Allocate-on-flush 在sync/flush之前，尽可能多的积累更多的文件数据块才进行空间分配，一方面可以提高局部性，另一方面可以降低磁盘碎片。 几百字节的小文件不单独分配磁盘空间，直接把数据存放到文件的元数据中。 针对上述的本地文件系统特性，Curve文件系统分配需要着重考虑 。 局部性 虽然Curve是一个分布式文件系统，但是单个文件系统的容量可能会比较大，如果在空间分配时，不考虑局部性，inode中记录的extent数量很多，导致文件系统元数据量很大。© XXX Page 3 of 11 假如文件系统大小为1PiB，空间分配粒度为1Mi

inode+dentry方式？当前curve块存储的kv方式？ 是否有单独的元数据管理服务器？ 2、其他文件系统的调研总结 fs 中心化元数据 内存namespace元数据 内存空间分配元数据 元数据持久化 元数据扩展 小文件优化 空间管理单位 数据持久化 其他© XXX Page 3 of 24 moosefs（mfs） 有元数据服务器 全内存 fsnode → hashtable(inode id) offset) etcd 差 块设备，最小10GB segment + chunk raft 块设备的元数据管理 cephfs 3、各内存结构体 时间复杂度 空间复杂度 特点 可用实现 Btree 一个节点上保存多条数据，减少树的层次(4~5层)，方便从盘上读取数据，减少去盘上读取次数。适合在盘上和内存组织目录树。 google，https://github astcommon/tr ，(LGPL) ee/master/src hash table O(1)~O(n) O(n) + table 需要占用额外空间，性能和hash表的大小有关，最理想可以达到O(1)复杂度，最差O(n)复杂度。 c++ stl unordered_map moose，使用c实现 4、curve文件系统的元数据内存组织 curv

Debezium A: PolarDB-X 全局 Binlog：完全兼容 • 与 MySQL Binlog 体验完全一致 • 保障分布式事务完整性 • 透明：下游系统或工具改造成本为零 • 实现复杂度高 Q: 分布式数据库有哪些问题要考虑Demo for Global Binlog with Flink CDCPolarDB-X Global Binlog 特性详情 提供与 MySQL 生态下游透明对接能力

补充元数据数据结构 2021-04-19 李小翠、吴汉卿、许超杰等 补充文件空间分配，讨论与确认 背景 调研 开源fs 性能对比 可行性分析 方案对比 对比结论 架构设计 卷和文件系统 元数据架构 文件系统快照 方案一：文件/目录级别快照 方案二：文件系统快照 关键点 元数据设计 数据结构 索引设计 文件空间管理 开发计划及安排 背景 为更好的支持云原生的场景，Curve需要支 是友好的，但需要重新实现一套快照逻辑；第二种方案的改动和实现相对简单，并且对于需要备份的场景也是够用的。从可解决程度和解决的必要性考虑，选择第二种方 案。 关键点 mds volume 文件空间管理 文件系统的元数据所在的copyset分配策略（前期可以考虑都分配到同一个copyset上） metaserver inode/dentry的内存组织形式 数据持久化 client curvefs 等信息，inode 中记录文件空间占用、文件属性等信息，通过共享 inodeID 实现数据共享。curve的文件元数据管理设计为分布式的，因此第一种通过内存实现数据共享的方式并不适用，我们选择第二种方式。具体的元数据结构设计：Curve文件系统元数据管理（已实现） 索引设计© XXX Page 11 of 14 1. 2. 3. 4. 文件空间管理 文件空间管要解决的问题是：一个文

curve块设备的copyset是在空间预分配的时候就确定了，每次预分配1GB的空间，然后这1GB的空间每个chunk对应的copyset在预分配的时候已经确定。后续的读写的操作直接去对应的copyset上去进行读写。这个 分配copyset方式，并不适合curvefs的元数据。这种分配方式是提前分配了一批空间，即使用户只需要写4KB数据，也一次性分配1GB的空间。而curvefs的元数据，并不能一 一台机器上能存放多少个inode和dentry 由于元数据全部缓存在本地，而且磁盘空间远大于内存空间，所以一台机器上能放多少个inode和dentry最大的限制在于内存。 按照最差的情况，文件里面全部都是碎片，那么metaserver上的空间碎片将会占用最多的空间。这里忽略掉其他次要的因素，考虑全是空间碎片信息，每条记录只保存4KB数据，可以保存多少元数据。 选取占用空间更多的S3ChunkInfo。按照一台metaserver ver 256GB内存容量全部用来保存空间分配计算。可以的保存chunkinfo 条数 = 256GB / 64B = 4G。可以保存的文件的大小为4G * 4KB = 64TB的空间。 inode和dentry按照1:1估算，dentry按照name使用最大字节，选择占用空间更多的s3来计算。 文件大小 dentry大小 inode大小 可以保存inode和dentry数 1MB 312B

感知具体格式 提供不同文件类型支撑不同上层应用数据组织形式 • PageFile/AppendFile/AppendECFile • Segment • 逻辑概念，空间分配的基本单元 （减少元数据数量） • 多个连续地址空间chunk（物理文件）的聚合数据组织形式 • CopySet • 逻辑概念 • 减少元数据数量 • 数据放置的基本单元 • 提高数据可靠性 • 包含多个chunk of Data Loss in Cloud Storage」数据组织形式 • PageFile • 地址空间到—>chunk: 1 : N chunk有先后关系 • 创建时指定大小，lazy分配chunk • 提供4kb随机读写能力数据组织形式 • PageFile • 地址空间到—>chunk: 1 : N chunk有先后关系 • 创建时指定大小，lazy分配chunk • 提供4kb随机读写能力 AppendFile • 地址空间到—>chunk: 1 : 1 • 采用append的方式写入数据组织形式 • AppendFile • 地址空间到—>chunk: 1 : 1 • 采用append的方式写入 • 支撑多副本对象存储 通过文件/特殊目录隔离 挖洞即时回收 单独的元信息的存储方案数据组织形式 • AppendECFile • 地址空间到—>chunk: 1 : 1

含有一系列的扩展属性。每一个属性由一个名字以及与之相关联的数据所表示。其中名字必须为一个 字符串 ，并且必须有一个 命名空间 前缀标识符与一个点字符。目前存在有四种命名空间：用户命名空间、信任命名空间、安全命名空间以及系统命名空间。用户命名空间在命名或者内容上没有任何限制。系统命名空间主要被内核用于访问控制表上 。目前Linux 的 ACL 存储实现就是基于这种扩展属性的。 Inode Table中保存有若干个 Ext4_inode ，每个 Inode 大小为 ext4_super_block 中指定的 s_inode_size, 然而一个 Inode 不一定用到这么多的大小，节点信息只用到 128 个字节的空间。剩下的部分作为扩展文件属性 (Xattr)，扩展属性内部是由一个扩展属性头和若干个扩展属性实体项构成的。© XXX Page 29 of 33 // fs/ext4/xattr.h struct

yset，metaserver ip等信息，然后从metaserver获取inode结构，缓存之； 判断inode结构中，对应请求[off, size]位置的空间是否有分配：如果未分配或只有部分分配空间，则调用空间分配器分配空间，并根据空间分配器返回结果，修改inode结构（包括file length）; inode修改需要持久化到底层并修改本地cache； 调用curve client接口，写curve卷对应[offset，len] 这两个函数的功能是类似，都用来创建文件。 根据parent inode id 和name，向mds查询创建dentry和inode的位置，去meta server创建dentry和inode 预分配一些空间？可先不做 mkdir© XXX Page 7 of 11 void (*mkdir) (fuse_req_t req, fuse_ino_t parent, const char *name,

共同一致（joint consensus） • 集群先切换到一个过渡的配置(old + new)，一旦共同一 致已经被提交，系统切换到新的配置(new)。RAFT协议简介 日志压缩 • 日志会不断增长，占用空间 • 采用快照的方式压缩日志 • 在某个时间点，整个系统的状态都以快照的形式写入 到稳定的持久化存储中 • 完成一次快照之后，删除时间点之前的所有日志和快 照。BRAFT简介 • raft协 mds：保存元数据，包括topo信息、文件系统信 息、元数据分布信息等，持久化到etcd中。 • metaserver：采用raft协议3副本的方式保存文 件文件的元数据，包括inode，dentry，文件的 空间分配信息。 • 数据集群：采用外部存储，S3或者Curve块存储，保 存写入文件的数据。Curve文件存储RAFT应用 基于rocksdb的存储引擎 • 要求存储的元数据的大小不超过内存的大小 问题背景： raft的快照需要定期打快照，用来清理log。对于Curve块存储场景，系统状态就是Chunk当前的数据。 如果把所有chunk 拷贝一遍打快照，会出现两个问题： 1. 每次快照，空间上要多出1倍，空间浪费严重。 2. Curve块存储快照间隔默认30 分钟一次，每次快照会产生大量的数据拷贝，占用chunkserver的 处理能力，对磁盘造成很大压力，影响正常IO。 解决思路： ch

Get、PUT、DEL 和其他扩展 通常意义是支持 POSIX 接口 传统意义的文件系统： Ext4 对指定地址空间进行随机读写 传统意义的块存储：磁盘分布式存储的要素 如何构建分布式文件系统？ 以分布式块存储为例。 •提供大容量的块设备 •可以在指定地址空间内随机读写 write(offset, len) •服务质量要求：数据不能丢、服务随时可用、弹性扩缩容 要什么 •成百上千台存储节点 续监控、错误检测、容错与自动恢复的能力 以达到高可靠、高可用、高可扩分布式存储的要素 要 素 拆 解 数据分布 —— 无中心节点/中心节点 均 衡 地址空间的每段数据会分布在不同机器的磁盘上，如 何找到这些数据？ 可靠性 & 可用性 —— 多副本/EC 服务不可用时 间 数据一致性 —— 一致性协议 如何保证数据不丢？如何保证各种硬件故障的时候读 | 使用中的问题 Curve 架构简介 | 主要亮点 | 应用情况 FAQ 答疑架构简介 — 总体架构 支持块存储、文件存储（多种存储后端）架构简介 — 概念介绍 Segment: 空间分配的基本单元 Chunk: 数据分片 Copyset: 复制组 ChunkServer: 管理一个磁盘进程架构简介 — 数据放置 Copyset的放置 Chunk的分配 • 由中心节点MDS以Scatter-width