curvefs chunkid 持久化 ## 背景 1. 将原有的获取chunkid的方法从space迁入mds中，并持久化写入etcd中； 2. 只考虑单mds工作的情况； 3. chunkid全局递增。 ## 实现 1. proto/space.proto 中的 message AllocateS3ChunkRequest、message AllocateS3ChunkResponse AllocateS3Chunk复制到proto/space.proto/service/MdsService中； 4. curvefs/src/mds/mds_services.h MdsServiceImp类中增加 AllocateS3Chunk 实现； 5. curvefs/src/mds/mds_services.h MdsServiceImp类中增加 ChunkIDGenerator 类对象，方法 1. 构造函数 初始化 2. init 函数：用于初始化或者更改 ChunkIdAllocatorImpl 的一些配置。但是这些配置不会立即生效，而是等到当前 chunkId池枯竭时才会生效。 3. 析构函数 4. GenChunkID 1. 申请的chunkID池是否枯竭? 1. 是，使用 KVStorageClient 申请新的 chunkid Bundle （etcd

元数据持久化 • 前言 • Raft Log • Raft Snapshot - 持久化文件 - key value pairs - 其他说明 实现 • 1、inode、entry 的编码 • 2、KVStore • Q&A • 单靠 redis 的 AOF 机制能否保证数据不丢失? • redis 的高可用、高可扩方案? • redis + muliraft redis 中哈希表实现的优点? ## 前言 根据之前讨论的结果，元数据节点的架构如下图所示，这里涉及到两部分需要持久化/编码的内容： • Raft Log: 记录 operator log • Raft Snapshot：将内存中的数据结构以特定格式 dump 到文件进行持久化 copyset-2 copyset-1 ![Image](/uploads/documents/8/5/d/ |checksum|8|前面5部分的校验和| Raft Snapshot ## 持久化文件 |字段|字节数|说明| |---|---|---| |CURVEFS|7|magic number（常量字符 "CURVEFS"），用于标识该文件为 curvefs 元数据持久化文件| |version|4|文件版本号（当文件格式变化时，可以 100% 向兼容加载旧版持久化文件）| |size|8|键值对数量| |key

CurveFS方案设计（总体设计，只实现了部分） |时间|修订人|修订内容| |---|---|---| |2021-03-23|李小翠|初稿(背景，调研，架构设计)| |2021-03-30|李小翠|增加快照部分| |2021-04-13|李小翠、陈威|补充元数据数据结构| |2021-04-19|李小翠、吴汉卿、许超杰等|补充文件空间分配，讨论与确认| 背景 • 调研 • 开源fs • 能通用文件系统，其中高性能主要是适配云原生数据库的场景。当前Curve是实现了块存储，向上提供块设备服务，CurveFS会基于此实现。第一阶段的目标是实现满足数据库场景的文件接口。 调研 开源fs 当前对已有的开源分布式文件系统进行了调研，主要包括系统架构，元数据内存结构，元数据持久化，调研文档如下： chubaofs: ChubaoFS moosefs: https://kms.netease 互。这里需要确认的一点是：我们需要怎样的元数据节点的性能？ ## 可行性分析 ## 方案对比 根据上述调研和测试结果，我们考虑了三种curvefs的元数据设计方案： ### 1. CurveFS kv方案设计 curve实现块设备时，元数据不是扁平化的设计，而是采用有目录层级的 namespace 方式，namespace 已经实现了 fs 元数据管理的雏形，具备了基本的元数据管理功能。（当时为什么要设计为

CurveFS Client 概要设计（已实现） 背景 - 概述 - 关键接口分析 - init - destroy - lookup - write - read • open • create & mknod • mkdir • forget • unlink • rmdir • opendir • readdir |时间|作者|内容| |---|---|---| |2021-04-27|许超杰|初稿| |||| |||| |||| ## 背景 CurveFS初步设计见 CurveFS方案设计（总体设计，只实现了部分），目前需细化Client端设计 ## 概述 CurveFS client 向上提供两层接口，分别是 对接fuse，提供通用文件系统接口。对于fuse接口，先前进行了一些调研，见FUSE调研 判断inode结构中，对应请求[off, size]位置的空间是否有分配：如果未分配或只有部分分配空间，则调用空间分配器分配空间，并根据空间分配器返回结果，修改inode结构（包括file length）；inode修改需要持久化到底层并修改本地cache； ■ 调用curve client接口，写curve卷对应[offset, len]数据。（这里涉及到一个问题，是否从fuse下来的请求是4k对齐的，如果不是，那么这里还需要修改为read

CurveFs 用户权限系统调研（已实现） ## 一、 Curvefs测试 • 1. 启动curvefs • 问题1：root用户无法访问挂载目录 • 测试 allow root - 测试allow_other • 参考文献 - 问题2：本地文件系统挂载默认是共享的？ - 问题3：文件系统访问控制是在哪一层实现的？ ## 二、 文件系统权限管理 • 文件类型 • 文件权限 chmod、chown、setfacl、getfacl接口文件系统自己如何实现 • 结论： • 参考文献： ## 一、 Curvefs测试 代码：https://github.com/cw123/curve/tree/fs_s3_joint_debugging 环境：test2 ### 1. 启动curvefs 手动创建curve卷，/etc/curve/client.conf中配置卷所在集群信息。 启动服 volume（挂载目录为/tmp/fsmount） # wanghai01@pubbetal-nostest2:~/curvefs/curve$ ps -ef | grep curvefs | grep wanghai wanghai+ 2641513 1 0 13:44 pts/213 00:00:00 ./bazel-bin/curvefs/src/space_新知识/curve_fs_space_新知识_main wanghai+

存在，而 B 不存在） • 例 2：rename A→C（A 存在，而 C 存在） • 4. 当 2 个操作的 dentry 属于同一个 copyset 有什么不一样？ ## 背景 当前 curvefs 并没有实现 rename 接口，本文档是对 rename 接口实现的调研及方案设计。 rename 操作，主要操作的是 dentry，如 rename /dir1/file1 /dir2/file2，主要有 操作，一次提交事务（txid）操作 • MDS 中的 copyset 需要增加一个 txid 字段（需持久化） • txid 为 uint64（8 个字节），增加的存储量为 $ 8 * copyset $ 的数量 • MeteServer 中的每个 Copyset 需要增加一个字段 PendingTx（持久化在 MetaSever 中），因为每次 Client 来访问的时候都需要与这个 PendingTx

curvefs copyset与fs对应关系 |版本|时间|修改者|修改内容| |---|---|---|---| |1.0|2021/7/23|陈威|初稿| |1.1|2021/8/4|陈威|根据评审意见修改| |1.2|2021/8/9|陈威|增加详细设计| • 1、背景 • 2、chubaofs的元数据管理 • 2.1、meta partition的创建 • 2.2、meta partition的管理 partition和inode以及dentry的对应关系? • 3、curvefs的copyset和fs的对应关系 • 3.1 如何获取inodeid • 3.2 copyset fs共用吗? • 3.3 copyset个数是否可以动态调整? • 4、curvefs的topo信息 • 5、curvefs mds和metaserver的心跳 • 6、详细设计 • 6.1 创建fs ## 1、 背景 curvefs使用raft作为元数据一致性的保证。为了提高元数据的可扩展性和并发处理能力，采用元数据分片的方式管理inode和dentry的元数据。inode的分片依据是fsid + inodeid，dentry的分片依据是fsid + parentinodeid。借鉴curve块设备的设计思路，（补充copyset的设计文档在这），curvefs的元数据分片仍然按照的copyset的方式去管理。

curvefs对接s3方案设计（过程文档） |时间|修订人|修订内容| |---|---|---| |2021-05-20|胡遥|初稿| |2021-07-20|胡遥|细化 write 和 read 流程| • 整体架构 • 整体思路 · 接口和关键数据结构 • mds.proto • client端数据结构 • metaserver.proto • space相关数据结构和proto unk，以及block的拆分为s3的object，并写入/读取s3的object。S3-allocator模块：负责分配s3-object唯一标识。 ## 整体思路 curvefs对接s3和对接volume主要的区别在于数据持久化和空间分配部分，而元数据的操作尽量保持统一。因此我们涉及到修改client的流程主要在read/write/flush，以及空间分配申请（s3不需要释放空间，可直接删除对应s3 ，每个block最大4M，每个block对应s3上一个object。 s3上对象已chunkid_indexblock_version进行命名，元数据则已S3ChunkInfo（见数据结构）的方式存储在inode中。对于文件顺序写场景，文件0~4M的s3对象必然为chunkid_0_0_4M~8M为chunkid_1_0，以此类推，还有一种情况是文件先写了0~2M，然后在写2M~4M，这里会采用

curvefs client 删除文件和目录功能设计 背景 相关调研 moosefs chubaofs 方案设计思考 1. Trash机制是实现1个(类似chubaofs)，还是2个（类似moosefs）？ 2. Trash 放在哪里? 3. 是否需要做 session 机制（在 metaserver 打开），来维护 inode 的打开情况？ • 方案设计 • Trash机制： • 工作量评估 ## 背景 目前curvefs client版本对删除unlink和rmdir的设计只有简单的删除inode和dentry结构，遗留了nlink和lookup count相关的内容还未实现，是不完备的。本文首先调研moosefs，chubaofs等分布式系统，参考并设计解决上述遗留问题。 当前删除接口代码如下： CURVEFS_ERROR FuseClient::RemoveNode(fuse_req_t fuse_ino_t parent, const char *name) { Dentry dentry; CURVEFS_ERROR ret = dentryManager_->GetDentry(parent, name, &dentry) if (ret != CURVEFS_ERROR::OK) { LOG(ERROR) << "dentryManager_GetDentry