能，底层基于ext4文件系统，操 作实际的磁盘。 ChunkServer架构ChunkServer通过RPC网络层与client， MDS，其他ChunkServer通信。RPC 网络层是由brpc框架去完成的。包 括读写socket，rpc协议解析等。 ChunkServer架构RPC Service层是对外提供的一些RPC服 务的接口。包含的RPC服务有： • ChunkService。IO相关操作 绍文档中详细介绍。 ChunkServer架构Metric统计模块使用brpc中的bvar计数 器，统计一些IO层面和copyset层面的 一些指标，方便监控和跟踪。 ChunkServer架构并发控制层，负责对chunkserver的IO 请求进行并发控制，对上层的读写请 求安照chunk粒度进行Hash，使得不同 chunk的请求可以并发执行。 ChunkServer架构DataStore是对chunk落盘逻辑的封装。 克隆chunk的管理等等。 ChunkServer架构LocalFileSystermAdaptor是对底层文件 系统的一层抽象，目前适配封装了ext4 文件系统的接口。 之所以要做这层抽 象，目的是隔离了底层文件系统的实 际读写请求，如果将来curve要适配裸 盘或者采用其他文件系统，可以在这 层进行适配。 ChunkServer架构CURVE基本架构 01 02 03 04 ChunkServer架构

扩展性/可用性/可靠性 依赖于第三方kv存储，目前是etcd CurveFS 单机内存元数据设计 类似 fastcfs 和 moosefs 的元数据设计方式，采用通用的 dentry，inode 两层映射关系，所有的元数据都缓存在内存中，持久化在 binlog 文件中，binlog采用定期dump的方式删除。基于这种方式的开发： a. 性能 加载：数据量较大的情况下，元数据节点启动较慢；但是元数据使用 slave，slave 在内存中也缓存了全部元数据信息 master-slave 多副本数据 CurveFS 分布式元数据设计 类似 chubaofs 的元数据设计方式，同样是采用 dentry，inode 两层映射关系，所有的元数据都缓存在内存中。元数据是分片的，使用 multi-raft 持久化元数据以及保证多副本数据一致性。基于这种方式开发： a. 性能 由于元数据分片，获取元数据需要跟多个节点 近期要能支持mysql所要接口，长期需要支持通用文件接口。 kv 虽然改造简单，短期内对基本功能的支持没有问题，但这个架构不利于 Curve 长期的规划和演进，因此选择通用的 dentry，inode 两层映射的元数据结构。对于 fs© XXX Page 4 of 14 的场景，元数据的量比块存储场景会多很多，长期看元数据节点的设计也是需要满足高可用、高可扩、高可靠的。 因此对元数据节点的要求总结为：高可用、高可扩、高可靠、高性能。

9 Curve支持S3 数据缓存方案© XXX Page 2 of 9 版本 时间 修改者 修改内容 1.0 2021/8/18 胡遥 初稿 背景 整体设计 元数据采用2层索引 对象名设计 读写缓存分离 缓存层级 对外接口 后台刷数据线程 本地磁盘缓存 关键数据结构 详细设计 Write流程 Read流程 ReleaseCache流程 Flush流程 FsSync流程 能够预读1个block大小，减少顺序读对于底层s3的访问频次。从这个思路上该缓存方案主要针对的场景是顺序写和顺序 读，而对于随机写和随机读来说也会有一定性能提升，但效果可能不会太好。 元数据采用2层索引 由于chunk大小是固定的（默认64M），所以Inode中采用map s3ChunkInfoMap用于保存对象存储的位置信息。采用2级索引的好 写缓存一旦flush即释放，读缓存采用可设置的策略进行淘汰（默认LRU），对于小io进行block级别的预读。 即读写缓存相互没影响不相关， 缓存层级 缓存层级分为fs->file->chunk->datacache 4层，通过inodeId找到file，通过index找到chunk，然后通过offset~len找到是否有合适的datacache或者new datacache。 对外接口 流程上对于读写缓存有影响的

对于延迟分配和Inline file这两个特性，需要fuse client端配合完成。 空间分配 整体设计 分配器包括两层结构： 第一层用bitmap进行表示，每个bit标识其所对应的一块空间（以4MiB为例，具体大小可配置）是否分配出去。 第二层为free extent list，表示每个已分配的块，哪些仍然是空闲的（offset, length），以offset为key进行排 @brief© XXX Page 11 of 11 */ virtual uint64_t TotalFree() const = 0; }; MarkUsed和MarkFree是持久化层调用，对分配器进行初始化。

件进行写操作时也一样，首先写入到缓存中，然后由操作系统同步到块设备（如磁盘）中。对于通用块设备层来说要求io请求是块设备blocksize对齐的，对应buffered io在pagecache层做了对齐，对应direct_io需要用户层来保证。© XXX Page 18 of 23© XXX Page 19 of 23 实现：direct_io功能实现由VFS层提供，fuse也进行了支持，用户态文件系统要支持该flag需要在

HttpService: • Serivce层面区分上层请求为同步接口调用，还是异步接口调用， 同步接口调用直接调用Core层接口实现功能，异步接口创建Task， 并交由TaskManager调度。 SnapshotService & CloneService: • 任务管理层负责调度SnapshotTask和CloneTask，并向上提供如 cancel task等功能。 SnapshotTaskManager SnapshotCore & CloneCore:快照克隆服务器架构 • SnapshotDataStore负责管理快照转储的数据块，通过调用 S3Adaptor（一个封装了s3 client的接口层）与S3交互，存取s3 中的对象。 SnapshotDataStore: • SnapshotCloneMetaStore负责管理快照和克隆任务等元数据， 通过调用etcdclient，与et

client 向上提供两层接口，分别是© XXX Page 3 of 11 对接fuse，提供通用文件系统接口。对于fuse接口，先前进行了一些调研，见FUSE调研 提供lib库，提供对接分布式数据库接口，这一部分，可参考polarfs的接口，如下图所示。 根据讨论，我们首先对接fuse的lowlevel operators，对于数据库的lib库接口，后续可以在此基础上再做一层对接。lowlevel location，目前都在同一meta server，可先不实现） copyset cache & topo cache （可先不实现） mds client meta server client curve client （适配层） fuse impl main© XXX Page 10 of 11 接口设计 相关接口设计，见curve文件系统元数据proto（代码接口定义，已实现） Cache设计 Client的重要

启动curvefs 问题1：root用户无法访问挂载目录 测试 allow_root 测试allow_other 参考文献 问题2：本地文件系统挂载默认是共享的？ 问题3：文件系统访问控制是在哪一层实现的？ 二、文件系统权限管理 文件类型 文件权限 特殊权限(SUID, SGID, STICKY) 文件默认权限umask 用户&用户组 文件系统用户权限管理 对mode的管理 对ACL（Access "fuse.fuse_client", MS_NOSUID|MS_NODEV, "allow_other,fd=9,rootmode=40000,"...) = 0 问题3：文件系统访问控制是在哪一层实现的？ 测试curvefs，发现文件系统链路默认是没有做权限控制。（挂载点mode 777） # mountpoint wanghai01@pubbeta1-nostest2:/tmp$ ls -l

就越需要发送更多次读请求至s3. 最后导致无效旧数据的堆积和读请求性能的下降, 所以需要在合适的时候进行重叠元数据和数据的合并 原则是尽力而为, 并不能做到完美 方案 基于一下3个基础的数据结构, 2层索引 s3chuninfolist[index] = [s3chunkinfo(s)] s3chunkinfo { chunkid version // write always

作为LILO支持用户态的接口 • 如何评价LILO • 输出内核块设备I/O效率高 • 不利于把复杂的存储协议代码搬进内核，例如(curve, brpc, c++, protobuf 等) • TCMU多了一层转接，配置过程复杂，业界踩的坑不够多。 • TCMU的用户态代码会受到框架约束，不够灵活。iSCSI target 服务器 • TGT(STGT) • 比较久的历史，原来叫STGT，后来改成TGT