© XXX Page 1 of 14 CurveFS方案设计（总体设计，只实现了部分）© XXX Page 2 of 14 时间 修订人 修订内容 2021-03-23 李小翠 初稿(背景，调研，架构设计) 2021-03-30 李小翠 增加快照部分 2021-04-13 李小翠、陈威 补充元数据数据结构 2021-04-19 李小翠、吴汉卿、许超杰等 补充文件空间分配，讨论与确认 背景 背景 调研 开源fs 性能对比 可行性分析 方案对比 对比结论 架构设计 卷和文件系统 元数据架构 文件系统快照 方案一：文件/目录级别快照 方案二：文件系统快照 关键点 元数据设计 数据结构 索引设计 文件空间管理 开发计划及安排 背景 为更好的支持云原生的场景，Curve需要支持高性能通用文件系统，其中高性能主要是适配云原生数据库的场景。当前Curve是实现了块存储，向上 结果是合理的，分布式的元数据设 调研测试 计会涉及到多次rpc的交互。这里需要确认的一点是：我们需要怎样的元数据节点的性能？ 可行性分析 方案对比 根据上述调研和测试结果，我们考虑了三种curvefs的元数据设计方案： CurveFS kv方案设计 curve实现块设备时，元数据不是扁平化的设计，而是采用来有目录层级的 namespace 方式，namespace 已经实现了 fs 元数

XXX Page 1 of 15 rename 接口实现方案（已实现，选用方案二）© XXX Page 2 of 15 1. 2. 3. 4. 1. 2. 1. 3. 1. 2. 背景 方案调研 Chubaofs Juicefs 方案实现 方案一：chubaofs 方案二：事务方案 方案三：利用 KV 自带的分布式事务 Q&A 1. 是否需要实现跨文件系统的 存在) 4. 当 2 个操作的 dentry 属于同一个 copyset 有什么不一样？ 背景 当前 curvefs 并没有实现 rename 接口，本文档是对 rename 接口实现的调研及方案设计。 rename 操作，主要操作的是 dentry，如 rename /dir1/file1 /dir2/file2，主要有 2 个步骤：(1) 删除 file1 的 dentry，(2) 增加 inodeid 等同 file1 的 inode id）。 关于 rename 接口的实现，主要调研了 chubaofs 和 juicefs，而 rename 的实现难点主要在于其原子性的保证。 方案调研 Chubaofs chubaofs 中的 rename 实现不是原子性的，它是通 用创建源文件的硬连接，然后删除源文件的方式来实现的，主要有以下 4 步 ： 将源文件的 nlink 加一

© XXX Page 1 of 11 Curve文件系统空间分配方案（基于块的方案，已实现）© XXX Page 2 of 11 背景 本地文件系统空间分配相关特性 局部性 延迟分配/Allocate-on-flush Inline file/data 空间分配 整体设计 空间分配流程 特殊情况 空间回收 小文件处理 并发问题 文件系统扩容 接口设计 RPC接口 空间分配器接口 背景 根据 ，文件系统基于当前的块进行实现，所以需要设计基于块的空间分配器，用于分配并存储文件数据。 CurveFS方案设计（总体设计，只实现了部分） 本地文件系统空间分配相关特性 局部性 尽量分配连续的磁盘空间，存储文件的数据。这一特性主要是针对HDD进行的优化，降低磁盘寻道时间。 延迟分配/Allocate-on-flush 在sync/flush之前，尽可能多的积累更多的文件数

© XXX Page 1 of 9 Curve支持S3 数据缓存方案© XXX Page 2 of 9 版本 时间 修改者 修改内容 1.0 2021/8/18 胡遥 初稿 背景 整体设计 元数据采用2层索引 对象名设计 读写缓存分离 缓存层级 对外接口 后台刷数据线程 本地磁盘缓存 关键数据结构 详细设计 Write流程 Read流程 ReleaseCache流程 因此需要通过Cache模块解决以上2个问题。 整体设计 整个dataCache的设计思路，在写场景下能将数据尽可能的合并后flush到s3上，在读场景上，能够预读1个block大小，减少顺序读对于底层s3的访问频次。从这个思路上该缓存方案主要针对的场景是顺序写和顺序 读，而对于随机写和随机读来说也会有一定性能提升，但效果可能不会太好。 元数据采用2层索引 由于chunk大小是固定的（默认64M），所以Inode中采用map方案。 写缓存一旦flush即释放，读缓存采用可设置的策略进行淘汰（默认LRU），对于小io进行block级别的预读。 即读写缓存相互没影响不相关， 缓存层级 缓存层级分为fs->file->chunk->datacache

© XXX Page 1 of 11 curvefs对接s3方案设计（过程文档）© XXX Page 2 of 11 时间 修订人 修订内容 2021-05-20 胡遥 初稿 2021-07-20 胡遥 细化write和read流程 整体架构 整体思路 接口和关键数据结构 mds.proto client端数据结构 metaserver.proto space相关数据结构和proto

Curvefs-S3 本地写缓存盘方案© XXX Page 2 of 9 背景 方案设计 主要数据结构定义 方案设计思考 POC验证 背景 当前，s3客户端在写底层存储的时候是直接写入远端对象存储，由于写远端时延相对会较高，所以为了提升性能，引入了写本地缓存盘方案。也即要写底层存储时，先把数据写到本地缓存硬盘，然后再把本地缓存 硬盘中的数据异步上传到远端对象存储。 方案设计© XXX Page 3 int loadAllCacheReadFile() {}; private: std::string CacheReadDir_;© XXX Page 8 of 9 }; 方案设计思考 本地硬盘如何管理 借用linux本地文件系统进行管理，存储进本地硬盘的内容以文件的形式来表现。 配置一个目录用于本地硬盘的文件管理，对作为缓存盘的本地硬盘进行格式化并挂载到该目录(如

key_value_pairs 其他说明 实现 1、inode、entry 的编码 2、KVStore Q&A 单靠 redis 的 AOF 机制能否保证数据不丢失? redis 的高可用、高可扩方案？ redis + muliraft 存在的问题？ redis 改造 vs 自己实现? redis 中哈希表实现的优点？ 参考 前言 根据之前讨论的结果，元数据节点的架构如下图所示，这里涉及到两部分需要持久化/编码的内容： 无法保证数据 100% 不丢失（这主要是 redis 基于性能考量，毕竟纯内存数据库，如果利用 WAL 每次写文件再 sync，那么性能就会下降很多） 所以，单靠 redis 的方案是不行了. redis 的高可用、高可扩方案？ 主要是 redis cluster + 主从复制 (或者第三方 codis + 哨兵) redis cluster/codis 主要解决扩展性的问题，它会进行分片，每个

理制度，确保数据安全性 和质量，以及合规使用，防范数据泄露、流失、扩散等风险，人工智能产品终 止下线时妥善处理用户数据。 （c）研发者应确保模型算法训练环境的安全性，包括网络安全配置和数 据加密措施等。 （d）研发者应评估模型算法潜在偏见，加强训练数据内容和质量的抽查 检测，设计有效、可靠的对齐算法，确保价值观风险、伦理风险等可控。 （e）研发者应结合目标市场适用法律要求和风险管理要求，评估人工智 试和验证。 （i） 研发者应评估人工智能模型算法对外界干扰的容忍程度，以适用范 围、注意事项或使用禁忌的形式告知服务提供者和使用者。 （j） 研发者应生成详细的测试报告，分析安全问题并提出改进方案。 6.2 人工智能服务提供者安全指引 （a）服务提供者应公开人工智能产品和服务的能力、局限性、适用人群、 场景。- 14 - 人工智能安全治理框架 （b）服务提供者应在合同或服务协议中，以使用者易于理解的方式，告 。 （f） 重点领域使用者应合理限制人工智能系统对数据的访问权限，制定 数据备份和恢复计划，定期对数据处理流程进行检查。 （g）重点领域使用者应确保操作符合保密规定，在处理敏感数据时使用 加密技术等保护措施。 （h）重点领域使用者应对人工智能行为和影响进行有效监督，确保人工 智能产品和服务的运行基于人的授权、处于人的控制之下。 （i） 重点领域使用者应避免完全依赖人工智能的决策，监控及记录未采

团队希望使系统概念能为更多人所易于理解，特别是编程新手。 公司 数百家大小规模的公司在生产环境中使用 Rust 完成各种任务，包括命令行工具、Web 服务、 DevOps 工具、嵌入式设备、音视频分析与转码、加密货币、生物信息学、搜索引擎、物联网 （IOT）程序、机器学习，甚至是 Firefox 浏览器的重要部分。 开源开发者 Rust 适合那些希望构建 Rust 编程语言、社区、开发工具和库的开发者。我们非常欢迎你为 个元素而忘记了更新条件 while index < 4，则代码会 panic。这也使 程序更慢，因为编译器增加了运行时代码来对每次循环进行条件检查，以确定在循环的每次迭 代中索引是否在数组的边界内。 作为更简洁的替代方案，可以使用 for 循环来对一个集合的每个元素执行一些代码。for 循环 看起来如示例 3-5 所示： 文件名：src/main.rs fn main() { let a = [10, 20 表达式中增加了第二个分支。当文件不能被创建，会打印出一个不同 的错误信息。外层 match 的最后一个分支保持不变，这样对任何除了文件不存在的错误会使程 序 panic。 使用 match 处理 Result 的替代方案 这里有好多 match！match 确实很强大，不过也非常的原始。第十三章我们会介绍闭 包（closure），它会和定义在 Result 中的很多方法一起使用。在处理代码中的 Result

0 码力 | 562 页 | 3.23 MB | 21 天前

3

Page 2 of 15 背景 相关调研 moosefs chubaofs 方案设计思考 1.Trash机制是实现1个(类似chubaofs)，还是2个（类似moosefs）？ 2. Trash放在哪里？ 3. 是否需要做session机制（在metaserver打开），来维护inode的打开情况？ 方案设计 Trash机制： Session机制： 遗留问题 工作量评估 背景 sefs复杂，需要引入一些额外的复杂性。 由于是按目录管理trash，那么必须是两个trash（其中一个是reserve）以区分两种不同的情况。 chubaofs chubaofs的方案如下： chubaofs实现了类似trash的机制，称为freelist， 当inode被unlink时，client会发送UnlinkInodeRequest， 对应的metasever接收到 。 我们的整个架构设计本身就类似chubao方式，这个方案本身是chubaofs的成熟方案，说明是已经被验证过是可行的方案。 缺点： 由于link、unlink等接口涉及跨服务器的两个请求的处理，可能会存在孤儿inode的问题，这一情况，chubaofs是通过运维手段去修复，见遗留问题。moosefs由于单mds，不存在这个问题。 方案设计思考 首先我们可以确定以下几个设计点：