数据结构 索引设计 文件空间管理 开发计划及安排 背景 为更好的支持云原生的场景，Curve需要支持高性能通用文件系统，其中高性能主要是适配云原生数据库的场景。当前Curve是实现了块存储，向上提供块设备服务，CurveFS会基于此实现。第一阶段的目标是实现 满足数据库场景的文件接口。 调研 开源fs 当前对已有的开源分布式文件系统进行了调研，主要包括系统架构，元数据内存结构，元数据持久化，调研文档如下： 计会涉及到多次rpc的交互。这里需要确认的一点是：我们需要怎样的元数据节点的性能？ 可行性分析 方案对比 根据上述调研和测试结果，我们考虑了三种curvefs的元数据设计方案： CurveFS kv方案设计 curve实现块设备时，元数据不是扁平化的设计，而是采用来有目录层级的 namespace 方式，namespace 已经实现了 fs 元数据管理的雏形，具备了基本的元数据管理功能。（当时为什么要设计为 namespace 这种方式相当于每次都是全量缓存当前元数据，不做增量快照，考虑到转储逻辑，这也是可以接受的 对比这两种方案，第一种方案对于copy场景是友好的，但需要重新实现一套快照逻辑；第二种方案的改动和实现相对简单，并且对于需要备份的场景也是够用的。从可解决程度和解决的必要性考虑，选择第二种方 案。 关键点 mds volume 文件空间管理 文件系统的元数据所在的copyset分配策略（前期可以考虑都分配到同一个copyset上）

| 场景介绍 | 使用中的问题 Curve 架构简介 | 数据对比 | 应用情况 FAQ 答疑存储的发展 互联网时代，数据大爆炸 大型主机 成本高 单点问题 扩容困难 各存储设备通过网络互联 大规模 弹性扩容 底层构建在分布式存储之上 云的概念 成本：共用基础设施 弹性：随意扩缩容 速度：更快的构建发布业务 底层构建在分布式存储之上 云原生的概念： 易用性：跨平台，超融合，弹性 通常意义是支持 POSIX 接口 传统意义的文件系统： Ext4 对指定地址空间进行随机读写 传统意义的块存储：磁盘分布式存储的要素 如何构建分布式文件系统？ 以分布式块存储为例。 •提供大容量的块设备 •可以在指定地址空间内随机读写 write(offset, len) •服务质量要求：数据不能丢、服务随时可用、弹性扩缩容 要什么 •成百上千台存储节点 •磁盘故障、机器故障、网络故障概率性发生 • 所有副本写完成返回客户端 • 延迟取决于所有副本中最慢的那一个块存储场景 为云主机提供云盘，云盘提供随机读写、快照（数据备份，灾备使用）、镜像（模板，自定义）功能。块存储场景 为物理机提供块设备 Linux IO栈 应用程序 -> 文件系统 -> 块设备层 -> 不同协议/驱动使用中的问题 • io抖动（一致性协议）： 异常场景（比如阵列卡一致性巡检，坏盘，慢盘，网络异常），服务升级

能力，采用元数据分片的方式管理inode和dentry的元数据。inode的分片依据是fsid + inodeid，dentry的分片依据是fsid + parentinodeid。借鉴curve块设备的设计思路，（补充copyset的设计文档在这 ），curvefs的元数据分片仍然按照的copyset的方式去管理。 curve块存储的topo信息由PhysicalPool、LogicalPoo 据变成了元数据。 curvefs的topo信息设计可以由PhysicalPool、LogicalPool、Zone、Server、MetaServer、CopySetInfo组成。 curve块设备的copyset是在空间预分配的时候就确定了，每次预分配1GB的空间，然后这1GB的空间每个chunk对应的copyset在预分配的时候已经确定。后续的读写的操作直接去对应的copyset上去进行读写。这个 chubaofs的文件系统使用volume的来表示，在创建一个文件系统的时候，会创建3个meta partition和10个data partition。chubaofs的data partition的功能我们使用curve块设备替换。meta partition的创建，以及meta partition的管理的，下面会详细分析一下。 2.1、meta partition的创建 再创建文件系统的时候，会创建好指定大小的metapartition，meta

底座，完美支持云原生数据库的存算分离架 构 • Curve作为云存储中间件使用S3兼容的对象 存储作为数据存储引擎，为公有云用户提供 高性价比的共享文件存储 • 支持在物理机上挂载使用块设备或FUSE文件 系统开源社区 社区运营 生态共建 开源共建 源码兜底 技术领先 目标 方法 影响力 降本 获客 用户 开发者 操作系统 芯片 数据库 云原生 AI训练 大数据 社区生态Curve介绍 点初始状态一致的时候，保证节点之间状态一致。 raft日志复制RAFT协议简介 raft配置变更 • 配置：加入一致性算法的服务器集合。 • 集群的配置不可避免会发生变更，比如替换宕机的机器。 直接配置变更可能出现双主问题 • 共同一致（joint consensus） • 集群先切换到一个过渡的配置(old + new)，一旦共同一 致已经被提交，系统切换到新的配置(new)。RAFT协议简介 日志压缩 • 日志会不断增长，占用空间 device)、iscsi • 支持RDMA和SPDK Curve块存储架构 • client：接受用户请求。 • mds：保存元数据，包括topo信息、块设备信息、 数据分布信息等，持久化到etcd中。 • chunkserver：采用raft协议3副本的方式保存块 设备上的数据。 • snapshotCloneServer：卷的快照克隆服务，持久 化到S3中。Curve块存储RAFT应用 数据分布 •

TGT 服务器的优化块设备协议 • NBD • Linux专有块设备协议 • iSCSI • 广泛支持的外部设备协议（块，磁带等）Curve云原生存储支持块设备 • 通过NBD，只支持Linux • 通过SDK API，目前只支持Linux • PFS • 扩大使用范围 • 通过iSCSI支持更多系统，例如Windows, 类UNIX系统等，使用两项基础 技术 • TCP/IP target服务器 • LINUX LILO • 一般用于输出内核本地块设备 • TCMU • 作为LILO支持用户态的接口 • 如何评价LILO • 输出内核块设备I/O效率高 • 不利于把复杂的存储协议代码搬进内核，例如(curve, brpc, c++, protobuf 等) • TCMU多了一层转接，配置过程复杂，业界踩的坑不够多。 • TCMU的用户态代码会受到框架约束，不够灵活。iSCSI Initiator的dmesg不会显示这个信息TGT的性能问题 • 性能问题主要体现在不能有效使用多CPU • 对多个socket connection，在单线程里做event loop多路复用。 • 多个target时，如果挂的设备多，一旦客户端请求量大，就会忙不过来。 • 开源界有尝试修改 • 例如sheepdog的开发者提交过一个patch，但是测试效果不理想，分析 原因，event loop依然是瓶颈对TGT的性能优化

com/cw123/curve/tree/fs_s3_joint_debugging 环境：test2 1. 启动curvefs 手动创建curve卷，/etc/curve/client.conf中配置卷所在集群信息。 启动服务&client挂载卷：bash startfs.sh start volume (挂载目录为/tmp/fsmount)© XXX Page 3 of 33 # wa allow-other'以允许相应用户有权访问该文件系统，如果挂载者不是root还需要在/etc/fuse.conf（/usr/local/etc/fuse.conf）中增加配置项“user_allow_other”（该配置项是无值的）。详见libfuse官方文 档：https://github.com/libfuse/libfuse#security-implications # The file 自己的权限检查，而不是将权限检查推迟到文件系统，除了文件系统的任何权限检查之外，内核还会进行检查，并且两者都必须成功才能允许操作 。 。 。 内核执行标准的 UNIX 权限检查 如果文件系统在打开设备 fd 时的初始功能协商期间启用了 ACL 支持，则此挂载选项将被隐式激活。 在这种情况下，内核执行 ACL 和标准的 unix 权限检查 疑问：协商期间do_init()中的启用ACL的flags如何设置？

和 topo信息，这部分可先不实现（目前先支持单metaserver的情况下，可先不实现，由配置文件加载metaserver的ip） 与metaserver交互, 调用meta server接口获取文件系统元数据信息，调用meta server接口获取文件和目录信息等 与现有块设备client交互，调用块设备接口，对卷进行读写。 向上对接fuse接口，协调上述模块交互，实现功能。 main 主函数模 除上述功能以外，还需实现文件系统创建和fuse挂载工具，功能主要是： 创建文件系统，指定文件系统的名字、卷大小（多文件系统）、 扩展文件系统？ 挂载fuse文件系统，指定挂载点、文件系统名字或fsID、server ip（可从配置文件读取）。 模块划分 根据上述功能模块，将client划分模块 fs cache inode cache dentry cache location cache （inode location、dentry

本PageFile支持块设备、三副本AppendFile（待开发）支持在线对象存储、AppendECFile（待开发）支持 近线对象存储可以共存。 如上所示LogicalPool与pool为多对一的关系，一个物理pool可以存放各种类型的file。当然由于curve支持 多个pool，可以选择一个logicalPool独享一个pool。 通过结合curve的用户系统，LogicalPool可以通过配置限定特 定user使用的方式，实现多个租户数据物理 隔离（待开发）。TOPOLOGY Topology的实际例子，右侧是topo配置文件： 集群有一个物理pool，由3个zone组成，每个zone有1台server。 在物理pool上，还创建了一个逻辑pool，逻辑pool使用3个zone，采用 3副本，有100个copyset。 cluster pool1 zone1 zone2 zone3 间的通信将会非常复杂，例如复制组内Primary给Secondary定期发送心跳进行探活，在256K个复制组的情况 下，心跳的流量将会非常大；而引入CopySet的概念之后，可以以CopySet的粒度进行探活、配置变更，降低 开销。 3. 提高数据可靠性：在数据复制组过度打散的情况下，在发生多个节点同时故障的情况下，数据的可靠性会受 到影响。引入CopySet，可提高分布式存储系统中的数据持久性，降低数据丢失的概率。COPYSET

C=O_DSYNC|04000000）。 FASYNC: 异步的，启用signal-driven I/O。 : 直接I/O，执行磁盘I/O时绕过缓冲区高速缓存，从用户空间直接将数据传递到文件或磁盘设备。 O_DIRECT : 使得32位操作系统对大文件支持（_FILE_OFFSET_BITS=64）。 O_LARGEFILE : 以目录形式打开，如果pathname不是一个目录则会打开失败。 ，当虚拟文件系统读文件时，首先从缓存中查找要读取的文件内容是否存在缓存中，如果存在就直接从缓存中读取。对文 件进行写操作时也一样，首先写入到缓存中，然后由操作系统同步到块设备（如磁盘）中。对于通用块设备层来说要求io请求是块设备blocksize对齐的，对应buffered io在pagecache层做了对齐，对应direct_io需要用户层来保证。© XXX Page 18 of 23© XXX

提供4kb随机读写能力数据组织形式 • PageFile • 地址空间到—>chunk: 1 : N chunk有先后关系 • 创建时指定大小，lazy分配chunk • 提供4kb随机读写能力 • 支撑块设备应用场景 块设备层面的快照功能 即为文件层面快照数据组织形式 • AppendFile • 地址空间到—>chunk: 1 : 1 • 采用append的方式写入数据组织形式 • AppendFile