小版本一般1~2个月发布一次。  z为修订号，修复一批bug后递增。  后缀表示版本状态，beta表示测试版本，rc 表示发布候选版本，空白表示正式版。 Curve所有功能开发均在master分支进行，而版本发布则在相应的release分支进行：  从master拉出一个新分支release-x.y，打beta版标签后，提交QA团队测试 ；  beta版的bug修复代码先合入master分支，再c beta版bug修复完成后，打rc版标签（可能有多个rc版），上线到测试环境；  经bug修复和长时间运行测试后，若代码达到正式上线标准，则发布正式版。 v1.0.0-beta v1.1.0-beta master v1.1.0-rc0 release-1.1 v1.0.0-rc0 v1.0.0 v1.0.1 release-1.0 v1.0.0-rc1 新功能 Bug修复 cherry-pick 制造或模拟系统异常(磁盘错误、网络错误、资源 冲突等)、依赖服务异常、应用本身异常等非正常 情况，测试软件的性能和稳定性是否符合预期。  规模测试 测试模块在一定规模下是否能够正常工作，是否 会出现异常或者崩溃， 14/33系统测试 系统测试是对整个系统的测试，将硬件、软件、操作人员看作一个整体，检验它是否有不符 合系统说明书的地方。它是一个黑盒测试，可以发现系统分析和设计中的错误。 Cur

fs的成熟方案，说明是已经被验证过是可行的方案。 缺点： 由于link、unlink等接口涉及跨服务器的两个请求的处理，可能会存在孤儿inode的问题，这一情况，chubaofs是通过运维手段去修复，见遗留问题。moosefs由于单mds，不存在这个问题。 方案设计思考 首先我们可以确定以下几个设计点： 删除的大致过程如下，首先移除dentry，然后移除inode，可以容忍只存 successfully but inode is not, still returns success. 此时，nlink是没有-1的，删除接口直接忽略了第二步的错误。 根据其论文描述：© XXX Page 14 of 15 chubaofs使用的是类似fsck的工具去修复这个问题，也就是运维手段。 工作量评估 需要修改的模块，如下： Client端： 实现symlink、link接口； 修改unli

server超过offline的时间没有收到心 跳（默认30min）， chunkserver状态改为offline， 打印一条error日志。调度模块感知到offline状态， 触发chunk server的recover修复。 心跳正常 心跳正常 超过miss时间 未超过offline时间 UNSTABLE ONLINE OFFLINESCHEDULE Schedule（系统调度）是为了实现系统的自动容错和负载均衡，这两个功能是分布式 负载均衡，这两个功能是分布式 存储系统的核心问题，也是 curve 是否能上生产环境的决定因素之一。 • 自动容错保证常见异常（如坏盘、机器宕机）导致的数据丢失不依赖人工处理，可 以自动修复。 • 负载均衡和资源均衡保证集群中的磁盘、cpu、内存等资源的利用率最大化。SCHEDULE Schdedule的具体实现 Coordinator: 调度模块的对外接口。心跳会将 chunkserver上报上来的copyset信息提交给

通过iSCSI支持更多系统，例如Windows, 类UNIX系统等，使用两项基础 技术 • TCP/IP • SCSI • 替代SAN • 可靠性、稳定性方面有自己的的特色，使用raft副本一致性和copyset概念可以自动 修复损坏的副本，并且可扩容。无论在可靠性、稳定性还是性价比方面都很有优势， 使用廉价硬件搭建。iSCSI软件 • Client端: iscsi initiator，系统自带 • Linux open-iscsi

mds发起配置变更，copyset复制组执行 • 在curve自动容错和负载均衡时，需要进行raft配 置变更。 • 自动容错保证常见异常（如坏盘、机器宕机）导 致的数据丢失不依赖人工处理，可以自动修复。 • 负载均衡和资源均衡保证集群中的磁盘、cpu、内 存等资源的利用率最大化。 Curve块存储和文件存储的配置变更实现基本一致CURVE的RAFT配置变更 异常场景下配置变更 • ReplicaSchedule

yset信息。 7.2 mds端 1、需要实现topo模块 2、实现mds和metaserver的心跳 3、实现fs和copyset的分片策略的实现 4、实现出现异常场景下的数据恢复，副本修复的调度。 7.3 metaserver端 1、需要提供copyset的创建功能 2、由copyset负责inode和dentry的管理 3、定期向mds上报心跳，并根据心跳结果执行配置变更

dispatcher是边沿触发 ●写端句柄永远不会触发可读事件 ●写端句柄第一次epoll会返回可写，可写是brpc判断连接成功的措施 ●UcpCm从来不会写入pipe，如果pipe有可读字节，会打印错误，说明有地方遗漏了修 改。 ●Socket通过关闭UcpCm返回的句柄来关闭连接。此举和Socket原来代码一样，减少了修 改。UcpCm检测到pipe读端可读，关闭UcpConnection。 n处于Error 状态，再调 用UcpConnection::DataReady，进而调用Socket::StartInputEvent ●UcpConnection的Read函数发现了错误状态，于是返回读错误，进而导致Brpc关闭 socket，而我们的socket里的fd是pipe的写端，当比关闭时，UcpCm检测到pipe读端fd可 读并且EOF，进而检测到UcpConnection需要关闭。61

RPC有可能会失败，一般情况下 处理逻辑是sleep一个较短时间后重试，但是存在两种特殊的场景： Chunkserver Overload: 这种情况下，对应的RPC Response中返回的错误码是OVERLOAD，说明底层Chunkserver正在处理的 请求数量过多。按照一般重试逻辑，大概率情况下重试请求还是返回OVERLOAD，造成用户IO请求一直 无法返回。 加入睡眠时间指数

len) •服务质量要求：数据不能丢、服务随时可用、弹性扩缩容 要什么 •成百上千台存储节点 •磁盘故障、机器故障、网络故障概率性发生 有什么 分布式存储系统需要满足接口需求，并且有持续监控、错误检测、容错与自动恢复的能力 以达到高可靠、高可用、高可扩分布式存储的要素 要 素 拆 解 数据分布 —— 无中心节点/中心节点 均 衡 地址空间的每段数据会分布在不同机器的磁盘上，如

进程当前工作目录的相对路径，此时等同于open。 open flags flags定义 flags通过宏定义实现，定义见 ，主要包括如下flag fcntl.h # 红色是不支持且会执行结果错误；橙色是暂不确定但不影响写入结果；紫色为暂时无法测试；黑色是已经支持 #define O_RDONLY 00000000 #define O_WRONLY 00000001 #define O_RDWR