李小翠、吴汉卿、许超杰等 补充文件空间分配，讨论与确认 背景 调研 开源fs 性能对比 可行性分析 方案对比 对比结论 架构设计 卷和文件系统 元数据架构 文件系统快照 方案一：文件/目录级别快照 方案二：文件系统快照 关键点 元数据设计 数据结构 索引设计 文件空间管理 开发计划及安排 背景 为更好的支持云原生的场景，Curve需要支持高性能通用文件系统，其中高性能主要是适 Link 创建新的dentry, 指向同一个inode 文件系统快照 方案一：文件/目录级别快照 快照是文件系统或卷的只读副本，快照要求可以即时创建。类似 moosefs，curvefs 可以计划支持目录及文件级别的快照，目录级别和文件级别的快照可以认为就是cp的实现。 对于文件/目录级别的快照： 检查目的节点的父节点中是否有同名文件存在： 存在 若源节点类型为TYPE_DIRE 对应的方式，curve当前数据节点需要变更。因为chunk16MB的定长不适用于文件系统。另外快照逻辑无法复用。 利用已有的块设备构建curvefs, 需要实现空间分配器，可以复用快照逻辑做文件系统级别的快照。 对比两种方案：首先curve设计的初衷是提供一个存储底座，在这个底座上构建文件、块、对象等，第一种方式相当于重新开发了一套文件系统，并没有用到块设备的能力。另外第一种方式虽然更加灵活，在空间

和close接口，增加open计数，记录client端open的数量 增量client与metaserver session模块，定期refresh session 到metaserver，这个要做客户端级别的，不是文件级别的，防止rpc请求数量过多 MetaServer端功能一 Trash机制： 需要实现 接口， 进行nlink–，当nlink==0时，将inodeid 放入trash unlink

Curve 85.4% 89% curve Ceph 37.1% 43.3% ceph应用情况 Curve 在网易集团内有大规模的生产应用 为核心业务提供稳定的存储服务，单集群存数万个卷，储容量PB级别  网易集团内部业务： • 网易严选，网易云音乐 网易有道，网易游戏 网易Lofter，云信 在集团外有联合开发用户和测试用户  网易外部用户：

Q&A© XXX Page 9 of 12 单靠 redis 的 AOF 机制能否保证数据不丢失? 不能，因为 AOF 与 SET/DEL 这些操作不是同步进行的，即使刷入文件配置项 开启最高级别的 always 选项，也有可能丢失一个事件循环的数据，实现如下： appendfsync // : call(...) // propagate(...) feedAppendOnlyFile(cmd

就要求inodeId是永远不可重复。 读写缓存分离 读写缓存的设计采用的是读写缓存分离的方案。 写缓存一旦flush即释放，读缓存采用可设置的策略进行淘汰（默认LRU），对于小io进行block级别的预读。 即读写缓存相互没影响不相关， 缓存层级 缓存层级分为fs->file->chunk->datacache 4层，通过inodeId找到file，通过index找到chunk，然后通过o