curvefs s3数据整理(合并碎片、清理冗余) ## 背景 1. 只考虑单客户端，单metaserver 2. 为了解决的问题：客户端在对一个文件的某个部分多次写入后，同一个chunk会产生很多版本数据；而客户端在读的时候，会需要对这些chunk进行筛选和构建，得到有效的部分，越是散乱的状态，就越需要发送更多次读请求至s3．最后导致无效旧数据的堆积和读请求性能的下降，所以需要在合适的时候进行重叠元数据和数据的合并 行重叠元数据和数据的合并 3. 原则是尽力而为，并不能做到完美 ## 方案 基于一下3个基础的数据结构，2层索引 基于以下3个基础的数据结构，2层索引 s3chuninfolist[index] = [s3chunkinfo(s)] s3chunkinfo { chunkid version // write always 0, compact will increase it it offset len } s3 object 命名：chunkid_version_index (index 为 obj 在 chunk 内的 index) ## 执行步骤 1. 数据整理作为一个后台服务(线程池)，运行于metaserver，遍历metaserver的inode进行数据整理的尝试，入队inodekey，如果是已有inode任务，enqueue直接返回，不入队 2

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

Curvefs-S3 本地写缓存盘方案 背景 方案设计 主要数据结构定义 方案设计思考 POC验证 ## 背景 当前，s3客户端在写底层存储的时候是直接写入远端对象存储，由于写远端时延相对会较高，所以为了提升性能，引入了写本地缓存盘方案。也即要写底层存储时，先把数据写到本地缓存硬盘，然后再把本地缓存硬盘中的数据异步上传到远端对象存储。 ## 方案设计 ![Image] [Image](/uploads/documents/9/f/c/6/9fc63b0767f5155e352efe3f279f8480/p3_1.jpg) S3模块接收到写入后先写入写内存缓存页，如果满足持久化的条件后，那么则准备持久化。 做一个硬链接链接到该文件。 本次io在本地硬盘写入好之后，异步上传模块会适时把本地硬盘写缓存目录中的文件上传到远端对象存储集群，上传成功后，删除本地写缓存目录中的对应文件。 件。 同时，缓存清理模块会定时检查本地硬盘缓存目录容量情况，如果容量已经达到阈值了，则进行文件的清理工作。 另外，异常管理模块处理客户端挂掉后的文件重新上传问题。 ## 主要数据结构定义 class DiskCacheManagerImpl : public DiskCacheManager{ public: DiskCacheManagerImpl(); virtual

Curve支持S3 数据缓存方案 |版本|时间|修改者|修改内容| |---|---|---|---| |1.0|2021/8/18|胡遥|初稿| ||||| 背景 · 整体设计 - 元数据采用2层索引 - 对象名设计 - 读写缓存分离 • 缓存层级 • 对外接口 • 后台刷数据线程 • 本地磁盘缓存 - 关键数据结构 - 详细设计 - Write流程 Read流程 - ReleaseCache流程 - Flush流程 - FsSync流程 - 后台流程 • poc测试验证 ## 背景 基于s3的daemon版本基于基本的性能测试发现性能非常差。具体数据如下： nuyao@pubbetal-nostest2:~/mnt$ fio -bs=4k -direct=1 --fallocate=none -size=10M -iodepth=1 append接口目前采用先从s3 get，在内存中合并完后再put的方式，对s3操作过多 2. 对于4k 小io每次都要和s3交互，导致性能非常差。 因此需要通过Cache模块解决以上2个问题。 ## 整体设计 整个dataCache的设计思路，在写场景下能将数据尽可能的合并后flush到s3上，在读场景上，能够预读1个block大小，减少顺序读对于底层s3的访问频次。从这个思路上该缓存

创建对象（直接调用构造器） java: Java = Java() 返回值 java void kotlin Unit ## kotlin 的类型推断 1 // 数据类型 首字母大写 2 var age: Int = 18 3 // 因为类型推断，基本数据类型可以省略 4 var age = 18 ## 修饰符 internal 类似 public、private internal 新增的可见性修饰符，表示当前模块可见。防止跨模块访问 48/p4_2.jpg) 基本数据类型的 ArrayOf()，在前面添加如 IntArrayOf()、FloatArrayOf()... java 里的基本数据类型，都是直接的值，而 kotlin 中的 Int，String... 都是一个对象，都是可以调用方法的。 ## kotlin 里的基本数据类型 Int 是不可空类型 对应 java 里的基本数据类型 但是可以调用包装类的方法 Int

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: ChubaoFS moosefs: https://kms.netease.com/team/km_curve/article/27786 fastcfs:

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调研 提供lib库，提供对接分布式数据库接口，这一部分，可参考polarfs的接口，如下图所示。 *volpath) int pfs_getwd(char *buf) Figure 3: libpfs interfaces 根据讨论，我们首先对接fuse的lowlevel operators，对于数据库的lib库接口，后续可以在此基础上再做一层对接。lowlevel operators接口一共45个，如下： +init +destroy +lookup +forget +эйт +getattr

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+

[Image](/uploads/documents/0/8/a/e/08ae71a4727fd75ad27d07540ed4f15a/p6_1.jpg) CBD NBD iSCSI FUSE kernel NFS S3 HDFS Performance First File Storage Block Storage CurveBS NVMe SSD HDD EBS public cloud Passive/Active Data Lifecycle Management roadmap Third-party service Object Storage OSS/S3/RGW on-premises or public cloud Standard IA Archive HDFS Worm data Cold data ## Agenda Why develop