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 类对象，方法

CurveFS方案设计（总体设计，只实现了部分） |时间|修订人|修订内容| |---|---|---| |2021-03-23|李小翠|初稿(背景，调研，架构设计)| |2021-03-30|李小翠|增加快照部分| |2021-04-13|李小翠、陈威|补充元数据数据结构| |2021-04-19|李小翠、吴汉卿、许超杰等|补充文件空间分配，讨论与确认| 背景 • 调研 • 开源fs • 开发计划及安排 ## 背景 为更好的支持云原生的场景，Curve需要支持高性能通用文件系统，其中高性能主要是适配云原生数据库的场景。当前Curve是实现了块存储，向上提供块设备服务，CurveFS会基于此实现。第一阶段的目标是实现满足数据库场景的文件接口。 调研 开源fs 当前对已有的开源分布式文件系统进行了调研，主要包括系统架构，元数据内存结构，元数据持久化，调研文档如下： chubaofs: 数据设计会涉及到多次rpc的交互。这里需要确认的一点是：我们需要怎样的元数据节点的性能？ ## 可行性分析 ## 方案对比 根据上述调研和测试结果，我们考虑了三种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调研

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，主要有

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 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

curvefs对接s3方案设计（过程文档） |时间|修订人|修订内容| |---|---|---| |2021-05-20|胡遥|初稿| |2021-07-20|胡遥|细化 write 和 read 流程| • 整体架构 • 整体思路 · 接口和关键数据结构 • mds.proto • client端数据结构 • metaserver.proto • space相关数据结构和proto S3ClientAdaptor模块：负责将文件数据进行chunk，以及block的拆分为s3的object，并写入/读取s3的object。S3-allocator模块：负责分配s3-object唯一标识。 ## 整体思路 curvefs对接s3和对接volume主要的区别在于数据持久化和空间分配部分，而元数据的操作尽量保持统一。因此我们涉及到修改client的流程主要在read/write/flush，以及空间分配申请（s3不需要释放空间，可直接删除对应s3 4; required uint64 blockSize = 5; required uint64 chunkSize = 6; } mds.proto import "curvefs/proto/common.proto"; message CreateFsRequest { required string fsName = 1; required uint64

Curvefs-S3 本地写缓存盘方案 背景 方案设计 主要数据结构定义 方案设计思考 POC验证 ## 背景 当前，s3客户端在写底层存储的时候是直接写入远端对象存储，由于写远端时延相对会较高，所以为了提升性能，引入了写本地缓存盘方案。也即要写底层存储时，先把数据写到本地缓存硬盘，然后再把本地缓存硬盘中的数据异步上传到远端对象存储。 ## 方案设计 ![Image]