interface rpc CreateFs(CreateFsRequest) returns (CreateFsResponse); rpc MountFs(MountFsRequest) returns (MountFsResponse); rpc UmountFs(UmountFsRequest) returns (UmountFsResponse); rpc GetFsI uest) returns (GetFsInfoResponse);© XXX Page 6 of 15 // rpc UpdateFsInfo(UpdateFsInfoRequest) returns (UpdateFsInfoResponse); rpc DeleteFsInfo(DeleteFsInfoRequest) returns (DeleteFsInfoResponse); MetaServerService { // dentry interface rpc GetDentry(GetDentryRequest) returns (GetDentryResponse); rpc ListDentry(ListDentryRequest) returns (ListDentryResponse); rpc CreateDentry(CreateDentryRequest)

发送写请求给Chunkserver BRPC线程 10.Chunkserver处理完成后返回RPC Response 11.用户请求的所有子请求完成后，调用 IOTracker::Done 12.调用异步请求回调，返回用户CLIENT IO请求重试 IO分发线程将拆分后的子请求通过RPC请求发往指定的Chunkserver上，RPC有可能会失败，一般情况下 处理逻辑是sleep一个较短时间后重试，但是存在两种特殊的场景： Chunkserver Overload: 这种情况下，对应的RPC Response中返回的错误码是OVERLOAD，说明底层Chunkserver正在处理的 请求数量过多。按照一般重试逻辑，大概率情况下重试请求还是返回OVERLOAD，造成用户IO请求一直 无法返回。 加入睡眠时间指数退避，并加入一个随机值，避免sleep后大量重试又碰撞到一起。 RPC超时： 请求在chunkserver端处理请求 请求在chunkserver端处理请求处理时间长，导致请求的返回时间超过了预期的RPC超时时间。 这种情况下，如果重试请求的RPC超时时间不发生变化，也有可能会重复上述流程，导致用户IO请求迟迟 未能返回。所以，在这种情况下，重试请求会将RPC超时时间进行增加。CURVE基本架构 01 02 03 04 Client总体介绍 热升级NEBD总体介绍 新版本Client/NEBD性能优化NEBD 整体介绍 热升级之前，

statusCode = 1; } service MetaServerService { rpc UpdateInodeS3Version(UpdateInodeS3VersionRequest) returns (UpdateInodeS3VersionResponse); rpc UpdateInode(UpdateInodeRequest) returns (UpdateInodeResponse); // space interface rpc InitSpace(InitSpaceRequest) returns (InitSpaceResponse); rpc AllocateSpace(AllocateSpaceRequest) returns (AllocateSpaceResponse); rpc DeallocateSpace(DeallocateSpaceRequest) (DeallocateSpaceResponse); rpc StatSpace(StatSpaceRequest) returns (StatSpaceResponse); rpc UnInitSpace(UnInitSpaceRequest) returns (UnInitSpaceResponse); rpc AllocateS3Chunk(AllocateS3ChunkRequest)

作实际的磁盘。 ChunkServer架构ChunkServer通过RPC网络层与client， MDS，其他ChunkServer通信。RPC 网络层是由brpc框架去完成的。包 括读写socket，rpc协议解析等。 ChunkServer架构RPC Service层是对外提供的一些RPC服 务的接口。包含的RPC服务有： • ChunkService。IO相关操作 • CliService。成员变更相关操作 scheduler发现copyset1, 2, 3的副本CS1 offline， 生成change peer from CS1 to CS2的operator给这三个copyset ④ MDS通过RPC在CS2上创建copyset1,2,3这三个copyset ⑤ 假定三个copyset的leader都是CS3，在CS3的下一次心跳的 response中，下发第三步生成的三个operator et数量为0，CS2上 的copyset最多，生成change peer from CS2 to CS1的operator给 部分copyset，比如copyset1,2,3 ⑤ MDS通过RPC在CS1上创建copyset1,2,3这些copyset ⑥ 假定三个copyset的leader都是CS3，在CS3的下一次心跳的 response中，下发第四步生成的三个operator ⑦

局部性 延迟分配/Allocate-on-flush Inline file/data 空间分配 整体设计 空间分配流程 特殊情况 空间回收 小文件处理 并发问题 文件系统扩容 接口设计 RPC接口 空间分配器接口 背景 根据 ，文件系统基于当前的块进行实现，所以需要设计基于块的空间分配器，用于分配并存储文件数据。 CurveFS方案设计（总体设计，只实现了部分） 本地文件系统空间分配相关特性 文件系统重新加载时，再将所有的空间，按照上述的策略，进行分组管理。 接口设计 RPC接口 当前设计是把空间分配器作为内置服务放在元数据节点，所以请求的发起方是fuse client，元数据服务器接收到请求后，根据fsId查找到对应的文件系统的空间分配器后，将空间分配/回收的任务交给这个分配器进行处理，处理完成后，返回RPC。 空间分配器相关的RPC接口，及request/response定义如下。与 里的定义基本一致。 status = 1; } service MetaServerService {© XXX Page 9 of 11 rpc AllocateSpace(AllocateSpaceRequest) returns (AllocateSpaceResponse); rpc DeallocateSpace(DeallocateSpaceRequest) returns (DeallocateSpaceResponse);

能测试： 。测试结果c开发的moosefs和fastcfs元数据性能远优于go开发的chubaofs和c开发的cephfs，理论上分析这个结果是合理的，分布式的元数据设 调研测试 计会涉及到多次rpc的交互。这里需要确认的一点是：我们需要怎样的元数据节点的性能？ 可行性分析 方案对比 根据上述调研和测试结果，我们考虑了三种curvefs的元数据设计方案： CurveFS kv方案设计 c 两层映射关系，所有的元数据都缓存在内存中。元数据是分片的，使用 multi-raft 持久化元数据以及保证多副本数据一致性。基于这种方式开发： a. 性能 由于元数据分片，获取元数据需要跟多个节点进行rpc的交互，因此性能相比单机要弱一些 b. 扩展性/可用性/可靠性 使用 multi-raft, 扩展性、可用性和可靠性与元数据节点一致 对比结论 CurveFS 近期要能支持mysql所要接口，长期需要支持通用文件接口。 在数据库等场景，文件的目录层级较少，文件数量较少，文件很大。这种情况inode比较聚集，一般分布在几个复制组上。inode数量少。 以上这两种情况，以20TB为例，数据量在MB级别，client获取数据可以使用stream类型的rpc？ ③ 正常使用场景，有一定的目录层级，文件分配数量较多，文件较小。这种情况inode比较分散，一般分布在多个复制组上，inode数量较多。 client获取数据可以并发从多个复制组中获取。 数据结构的选取？

e的问题： client无论在进行unlink过程时，需要两步，第一步是删除dentry，第二步是nlink-1，那么在执行完第一步之后，client如果崩溃或者掉电，或者是发送nlink-1的rpc失败（可以重试，但重试仍有可能失败）， 这种情况下，就会存在nlink未被减1的情况，当所有硬链接都被删除后，就会出现孤儿inode。 moosefs由于只有一个mds节点看，所以不存在这个问题。 和close接口，增加open计数，记录client端open的数量 增量client与metaserver session模块，定期refresh session 到metaserver，这个要做客户端级别的，不是文件级别的，防止rpc请求数量过多 MetaServer端功能一 Trash机制： 需要实现 接口， 进行nlink–，当nlink==0时，将inodeid 放入trash unlink 需要实现trash逻辑，每个parition

的记录。最后修改fs状态为INITED。© XXX Page 10 of 19© XXX Page 11 of 19 6.2、挂载fs 挂载fs的流程不变，client向mds发送mount rpc请求，mds对fs进行相应的检查，然后记录挂载点返回成功。 1、检查文件系统是否存在 2、检查fs的状态，是否是INITED状态 3、检查挂载点是否已经存在 6.3、创建文件/目录 cli 1、需要提供copyset的创建功能 2、由copyset负责inode和dentry的管理 3、定期向mds上报心跳，并根据心跳结果执行配置变更 metaserver 子模块拆分 metaserver service：接受rpc请求 copyset：负责对元数据的持久化，主要是一致性协议raft的处理© XXX Page 18 of 19 metastore：负责元数据的内存部分的管理，负责选partition pa

步就必须通过两次请求。相对于分片方式一，这种方式，client向metaserver进行查询的时候，rpc请求的个数近似翻倍，多一倍的查询，对性能上的影响能否接受。 inode的查询在client端其实有缓存。只有第一次查询的时候，client才需要去metaserver进行查询，以后对文件的操作，只需要使用本地缓存的inode信息。这样一来，查询inode多一倍的rpc请求，对性能的影响 可能没有想象中的大。一旦client知道了

proto； 修改 AllocateS3ChunkResponse 的状态码的类型为 FSStatusCode; proto/space.proto/service SpaceAllocService中的 rpc AllocateS3Chunk 复制到 proto/space.proto/service/MdsService中; curvefs/src/mds/mds_services.h MdsServiceImp类中增加