限于内存，而且在元数据服务启动的 时候，需要等待一段时间加载内存。 一种是元数据需要全部加载到内存，这种情况下，元数据只需要加载一小部分主要的元数据，比如说super block这种，剩下的比如inode，dentry这种，按需加载，而且使用淘汰机制，内存中不常用的元数据可以淘汰出去。这种方式，扩展性好，元数据服务的扩展性不受限于内存，服务上的内存只有几百GB，而硬盘空 间按照20块1.6TB的 6TB的盘来计算，一个服务器上可以有32TB的空间，硬盘的空间比内存到100多倍。但是这种方式，由于数据不能去全部缓存到内存，在查询元数据的时候，需要去盘上读数据，而且在文件系统这种使 用场景下，一次对文件的查找，需要在磁盘上读取多次。 我们的文件系统定位是一个高性能的通用文件系统，元数据的缓存倾向于全缓存。 系统加载的时候从持久化介质中进行加载，需要把一条条持久化的记录加载到内存里。实现把strin

小需求（改动小）将实现思路记录到任务管理系统中（JIRA），即可进行开发；  大需求（新模块、复杂功能）需要输出独立设计文档，并进行评审；对于功能或 性能影响较大的功能，还需要进行POC验证；评审和验证通过后才能启动开发 工作。 小需求 实现思路 开发 大需求 设计文档 POC 开发 7/33设计文档规范 设计文档需要具备以下内容：  修订记录  审批记录  系统介绍  相关调研  各ChunkServer上全部copyset，其副本分布的 ChunkServer总数量均衡。 30/33网络丢包10% 自动故障恢复 Curve可在多种软硬件故障场景（如单mds故障、单ChunkServer故障、硬盘故障、网络丢包等） 实现自动恢复，保障存储服务高可用性。  多对多，恢复时间短  精确的流量控制，对io影响很小 Kill一个节点所有ChunkServer进程 31/33快照克隆工具snaptool

存储时，先把数据写到本地缓存硬盘，然后再把本地缓存 硬盘中的数据异步上传到远端对象存储。 方案设计© XXX Page 3 of 9 S3模块接收到写入后先写入写内存缓存页，如果满足持久化的条件后，那么则准备持久化。 如果未配置本地硬盘作为写缓存，那么直接持久化到远端的对象存储；如果配置了本地硬盘作为写缓存，那么则尝试先写入本地硬盘写缓存目录。 写本地硬盘缓存目录之前先判断缓存目录容 直接写入到远端对象存储；否则，则写入到本地硬盘写缓存目录中。文件写入本地硬盘写缓存目录后，从本地硬盘读目录© XXX Page 4 of 9 做一个硬链接链接到该文件。 本次io在本地硬盘写入好之后，异步上传模块会适时把本地硬盘写缓存目录中的文件上传到远端对象存储集群，上传成功后，删除本地写缓存目录中的对应文件。 同时，缓存清理模块会定时检查本地硬盘缓存目录容量情况，如果容量已经达到阈值了，则进行文件的清理工作。 std::string CacheReadDir_;© XXX Page 8 of 9 }; 方案设计思考 本地硬盘如何管理 借用linux本地文件系统进行管理，存储进本地硬盘的内容以文件的形式来表现。 配置一个目录用于本地硬盘的文件管理，对作为缓存盘的本地硬盘进行格式化并挂载到该目录(如果没有缓存盘，那一般而言就是系统盘本身了)。 本地缓存盘的文件内容表示 本地缓存盘存放的文件即是存储到对象存储中的对象。

© XXX Page 1 of 33 CurveFs 用户权限系统调研（已实现）© XXX Page 2 of 33 一、Curvefs测试 1. 启动curvefs 问题1：root用户无法访问挂载目录 测试 allow_root 测试allow_other 参考文献 问题2：本地文件系统挂载默认是共享的？ 问题3：文件系统访问控制是在哪一层实现的？ 二、文件系统权限管理 文件类型 代码：https://github.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 -o conf=./curvefs/conf/curvefs_client.conf /tmp/fsmount 问题1：root用户无法访问挂载目录 测试发现client mount进程是哪个用户启动的就只有该用户(filesystem owner)可以访问该目录，即使挂载点mode是777。 # filesystem owner wanghai01@pubbeta1-nostest2:/tmp$

ds故障可能会导致client端无法写入。 因此，mds需要做高可用。满足多个mds, 但同时只有一个mds节点提供服务，称该提供服务的mds节点为主，等待节点为备；主节点的服务挂掉之后，备节点能启动服务，尽量减小服务中断的时间。 需要解决的问题就是：如何确定主备节点。 2. 技术选型 提供配置共享和服务发现的系统比较多，其中最为大家熟知的就是zookeeper和etcd, 考虑当前系统中 me ① 红色的点是etcd集群选主成功的时间点，选主成功之后MDS1的lease过期，Leader/MDS1被删除 ② 绿色的点是MDS2收到Leader/MDS1删除消息的时间点。此时MDS2启动并提供服务 ③ 黄色的点是最坏情况，MDS1在绿色点和红色点之间成功get到leader/MDS1, 在下一个周期get失败 这种情况下出现双主的最长时间为PeriodicGetTime(蓝色直线段)， ElectionTimeout=3s ElectionTimeout=10s GetTimeout=10s PeriodicGetTime=GetTimeout/5=2s MDS的启动时间：500ms左右 I0823 16:46:32.413305 22833 leader_election.cpp:25] 10.182.26.33:6666 campaign leader success

ChunkServer核心模块 新版本ChunkServer性能优化ChunkServer核心模块-注册和心跳 上报心跳 根据心跳下发raft成员变更 ChunkServer注册：chunkserver第一次启动时，需要向mds注册，mds分配并返回 ChunkserverID，token，chunkserver持久化这些信息，并在后续心跳上报时携带这些信息。ChunkServer核心模块-CopysetNode 初始状态，copyset1，copyset2，copyset3的三个副本分别在 CS2,CS3,CS4上，完成恢复后，CS2上的copyset1,2,3迁移到CS1上 ① CS1换了新盘，并重新格式化后启动chunkserver ② CS1重新向MDS注册 ③ MDS生成新的chunkserver id和token给CS1 ④ MDS的copyset scheduler发现CS1上的copyset数量为0，CS2上

dentry，inode 两层映射关系，所有的元数据都缓存在内存中，持久化在 binlog 文件中，binlog采用定期dump的方式删除。基于这种方式的开发： a. 性能 加载：数据量较大的情况下，元数据节点启动较慢；但是元数据使用 master-slave 可以降低 failover 情况下的加载时间 b. 扩展性/可用性/可靠性 扩展性不够，受限于单机的内存和磁盘，只能纵向扩展 可用性足够，由于是 wal 进行清理。snapshot 中存储的是键值对，其中 inode 文件中存储 inode-inodeInfo; dentry 中存储 filename-dentryInfo 信息 copyset 启动的时候根据 inode 和 dentry 分别建立对应的内存结构，再回放 wal 日志完成构建 卷的元数据管理 卷的元数据中需要包含建立在该卷之上的文件系统元数据分片的位置，以便进行元数据的索引

BRPC Socket对象 ●brpc最终的网络通讯都集中在socket对象里面 ●读socket通过EventDispatcher触发 ●上层发送网络数据通过写socket完成，不能立刻完成的，则去启动后台bthread去完成。11 BRPC SocketMap ●根据EndPoint作为一个map的Key，Value是Socket对象 ●Socket对象引用计数，多个Channel可以共享一个Socket对象

ate接口，可以由client直接修改inode的len，由metaserver的碎片整 理（马杰负责）模块进行truncate的无效数据清理 后台刷数据线程© XXX Page 4 of 9 启动后台线程，将写Cache定时刷到S3上，同时通过inodeManager更新inode缓存中的s3InfoList。具体细节见 本地磁盘缓存 如果有配置writeBack dev，则会调用dis