通过meta文件系统来管理trash，更为优雅。© XXX Page 8 of 15 1. 2. 1. 2. 1. 1. 2. 3. 4. 5. 缺点： moosefs是单mds，所以不存在接口原子性的问题，这块要重新考虑，我们实现上会比moosefs复杂，需要引入一些额外的复杂性。 由于是按目录管理trash，那么必须是两个trash（其中一个是reserve）以区分两种不同的情况。 可行的方案。 缺点： 由于link、unlink等接口涉及跨服务器的两个请求的处理，可能会存在孤儿inode的问题，这一情况，chubaofs是通过运维手段去修复，见遗留问题。moosefs由于单mds，不存在这个问题。 方案设计思考 首先我们可以确定以下几个设计点： 删除的大致过程如下，首先移除dentry，然后移除inode，可以容忍只存在inode，也就是孤儿inode情况，这部分内容见下面遗留问题。 meta文件系统来管理，更为优雅。 但是缺点是DEL和UNDEL需 ，这部分处理会引入 。（这个过程其实类似于rename） 要在trash下创建和删除dentry 额外的复杂性 由于moose是单文件系统，对于我们实现多文件系统，这里还有两种方案： ，二是每个fs一个trash，并且trash不能放在fs的根目录下，因为存在跟用户的目录重名的问题。 一是使用全局唯一的trash 倾向

数据chunk + 校验chunk数据组织形式 • AppendECFile • 地址空间到—>chunk: 1 : 1 • 数据chunk + 校验chunk • 支撑EC存储场景 多个单副本的 chunk 形成 EC 组 一个对象作为 EC 组的一个满条带 挖洞即时空间回收拓扑 • 管理和组织机器 • 软件单元：chunkserver • 物理机：server • 故障域：zone 完成后通知client； 5. Client通知用户请求完成。背景 01 02 03 04 总体设计 系统特性 近期规划单卷4K随机读写IOPS 102k 39.7k 41.7k 127k 4K随机写 4K随机读 Ceph（L/N） Curve 151.89% 204.56% 单卷4K随机读写平均延迟(ms) 1.244 3.2 3.1 0.998 4K随机写 4K随机读 61.12

s3数据整理(合并碎片、清理冗余)© XXX Page 2 of 3 1. 2. 3. 1. 2. 3. 4. 5. 6. 1. 2. 背景 只考虑单客户端, 单metaserver 为了解决的问题: 客户端在对一个文件的某个部分多次写入后, 同一个chunk会产生很多版本数据; 而客户端在读的时候, 会需要对这些chunk进行筛选和构建, 得到有效的部分

Intel(R) Xeon(R) Gold 5318Y CPU @ 2.10GHz ，256G，3副本，使用自带fio 高性能 NVME 块存储场景，Curve随机读写性能远优于Ceph 单卷 多卷主要亮点 — 易运维 运维场景 Curve Ceph 加盘 对IO无影响 秒级io影响 服务端升级 对IO无影响 重启管控面IO无影响，重启osd io秒级影响 客户端升级 热升级，秒级抖动 functions link Curve 85.4% 89% curve Ceph 37.1% 43.3% ceph应用情况 Curve 在网易集团内有大规模的生产应用 为核心业务提供稳定的存储服务，单集群存数万个卷，储容量PB级别  网易集团内部业务： • 网易严选，网易云音乐 网易有道，网易游戏 网易Lofter，云信 在集团外有联合开发用户和测试用户

Server性能优化 Curve最新的release1.1中对client和chunkserver分别进行了优化，fio性能测试的结果如下表格： Nbd 10盘： Nbd单盘：新版本ChunkServer性能优化 单深度fio测试chunkserver内部时延统计 Raft 日志落盘延迟 优化前性能分析：braft日志落盘时延占据了ChunkServer处理时延的50%以上，因此推断braft日志落盘存在瓶颈

struct，dentry struct） 缓存metaserver copyset 和 topo信息（目前先支持单metaserver的情况下，只需要一个metaserver的ip就可以） 与mds 交互，调用mds接口获取metaserver copyset 和 topo信息，这部分可先不实现（目前先支持单metaserver的情况下，可先不实现，由配置文件加载metaserver的ip） 与metaserver交互

Scatter-width（打散度）均衡 各ChunkServer上全部copyset，其副本分布的 ChunkServer总数量均衡。 30/33网络丢包10% 自动故障恢复 Curve可在多种软硬件故障场景（如单mds故障、单ChunkServer故障、硬盘故障、网络丢包等） 实现自动恢复，保障存储服务高可用性。  多对多，恢复时间短  精确的流量控制，对io影响很小 Kill一个节点所有ChunkServer进程

1. 1. 2. 1. 2. 3. 4. 3. 2. 背景 将原有的获取chunkid的方法从space迁入mds中，并持久化写入etcd中； 只考虑单 mds 工作的情况； chunkid全局递增。 实现 proto/space.proto 中的 message AllocateS3ChunkRequest、message AllocateS3ChunkResponse

daemon测试 ●估计非daemon模式的会更快一点，因为没有跨进程开销10/17/22 20 Write,DMA write,Write-zero测试10/17/22 21 fio 4k 1个并发+单深度10/17/22 22 Fio 4k 16并发单深度10/17/22 23 谢谢！

也分为两步，事务性也需要处理，留到下半年考虑。 6、curve文件系统的多文件系统的设计 curve文件系统设计上支持多文件系统。文件系统的super block元数据设计。 多文件系统相对于单文件系统，多了一个fsid，在上面的inode和dentry中，需要添加相应的fsId字段。并且在查询inode和dentry的过程中，也需要带上fsId字段进行查询。 Enum FsState {