redis 的 AOF 机制能否保证数据不丢失? redis 的高可用、高可扩方案？ redis + muliraft 存在的问题？ redis 改造 vs 自己实现? redis 中哈希表实现的优点？ 参考 前言 根据之前讨论的结果，元数据节点的架构如下图所示，这里涉及到两部分需要持久化/编码的内容： Raft Log：记录 operator log Raft Snapshot：将内存中的数据结构以特定格式 给 inode、dentry 增加编码函数 // 这里要尽可能减少 key/value 编码后的字节数，这样同样的内存可以存入较多的 key/value 对 序列化目前主要考虑以下 2 种，一种是参考 chubaofs 顺序编码，一种是利用 protobuf 直接序列化 顺序编码： 利用 protobuf（SerializeToString）进行序列化© XXX Page 6 of rehash 扩桶的时候），我们可以把 redis 中的哈希表借鉴过来用（redis 中的哈希实现很独立，单独的文件 t_hash.c，其性能表现也非常好） redis 哈希表实现主要优点参考以下 总的来说，我们只是参考 redis 持久化实现，而 redis 中的大头（各类数据结构、模块化、主从复制、集群等这些都是我们目前不需要的），因此去改造 redis 感觉不是很划算 redis 中哈希表实现的优点？

定期通过心跳向mds上报自己的状态。mds一方面根据metaserver上报的状态，进行相应的调度；另一方面根据心跳确认metasever 的存活状态。 这块内容参考的curve。metaserver定时向mds上报心跳，心跳内容参考curve。调度上，如果采用类似chubaofs的方案，那么copyset就会一直处于一个不均衡的状态中。如果copyset是可readwrite状态，新创建的 文 ReplicaScheduler: 副本数量调度器。根据当前copyset的副本数生成副本增删任务； RecoverScheduler: 恢复调度器。根据当前copyset副本的存活状态生成迁移任务。 结论：心跳参考curve。目前这些调度器在curvefs第一阶段不用全部实现。所有和均衡相关的，暂时不做。只做和故障处理相关的副本补全恢复的调度。 6、详细设计 6.1 创建fs curvefs管理工具发起 GenCopyset const ClusterInfo& cluster int numCopysets std vector Copyset * out 6.6、topology topology参考curve的topology的实现，由于curve的physical pool和logic pool在curvefs中合并成了一个，所以，并不能直接复用curve的topology的代码。 curve在创建logic

用户权限系统调研（已实现）© XXX Page 2 of 33 一、Curvefs测试 1. 启动curvefs 问题1：root用户无法访问挂载目录 测试 allow_root 测试allow_other 参考文献 问题2：本地文件系统挂载默认是共享的？ 问题3：文件系统访问控制是在哪一层实现的？ 二、文件系统权限管理 文件类型 文件权限 特殊权限(SUID, SGID, STICKY) 文件默认权限umask ACL的表示 内存中的ACL 是如何与具体的 Inode 相关联 如何存储和获取ACL信息 Inode权限校验 chmod、chown、setfacl、getfacl接口文件系统自己如何实现 结论： 参考文献： 一、Curvefs测试 代码：https://github.com/cw123/curve/tree/fs_s3_joint_debugging 环境：test2 1. 启动curvefs t2:/tmp# cd fsmount/ root@pubbeta1-nostest2:/tmp/fsmount# ls root@pubbeta1-nostest2:/tmp/fsmount# 参考文献 Why does root get Permission denied when accessing FUSE directory? man fuse 问题2：本地文件系统挂载默认是共享的？

如果不能合并，则向level2中插入一个新的extent。 小文件处理 大量小文件的情况下，按照上述的分配策略，会导致level1的bitmap标记全为1，同时level2中也会有很多extent。 所以可以参考chubaofs，对大小文件区分不同的分配逻辑。同时，将文件系统的空间划分成两个部分，一部分用于小文件的空间分配，另一部分用于大文件分配。两部分空间是相对的，一部分用完后，可以申请另 一部分的空间。 文件在第一次申请空间时，选择一个能满足要求的extent分配出去。后续的空间申请，同样要带上文件最后一个字节所在的地址空间，用于尽量分配连续的地址空间。 文件空间的申请，具体由大文件，还是由小文件处理，可以参考如下策略，大小文件阈值为1MiB：© XXX Page 6 of 11 并发问题 如果所有的空间分配和回收全部由一个分配器来进行管理，那么这里的分配很有可能成为一个瓶颈。 为了避免整个问题，可

client版本对删除unlink和rmdir的设计只有简单的删除inode和dentry结构，遗留了nlink和lookup count相关的内容还未实现，是不完备的。本文首先调研moosefs，chubaofs等分布式系统，参考并设计解决上述遗留问题。 当前删除接口代码如下：© XXX Page 3 of 15 CURVEFS_ERROR FuseClient::RemoveNode(fuse_req_t req, fuse_ino_t de按照inodeid分布，dentry按照parentid分布） 这种方案的优点是便于工具对trash进行查询，毕竟是实际的目录结构，完全遵循文件系统，可能可以复用client的当前设计，甚至可以参考moosefs实现一个meta文件系统来管理，更为优雅。 但是缺点是DEL和UNDEL需 ，这部分处理会引入 。（这个过程其实类似于rename） 要在trash下创建和删除dentry 额外的复杂性

具体flag的实现方案 O_TRUNC I/O模式类 O_DIRECT O_SYNC, O_DSYNC O_NONBLOCK(O_NDELAY ), FASYNC, O_TMPFILE 结论 参考文献 open接口原型 # man page open, openat, creat - open and possibly create a file #include int TIME进行测试（优先级中）。 3，目前I/O模式类flag（O_SYNC, O_DSYNC, O_NONBLOCK）经测试不会“影响“结果的正确性，后面继续对其实现方式进行研究（优先级中）。 参考文献 https://man7.org/linux/man-pages/man2/open.2.html https://www.cnblogs.com/BinBinStory/p/7400993

向上提供两层接口，分别是© XXX Page 3 of 11 对接fuse，提供通用文件系统接口。对于fuse接口，先前进行了一些调研，见FUSE调研 提供lib库，提供对接分布式数据库接口，这一部分，可参考polarfs的接口，如下图所示。 根据讨论，我们首先对接fuse的lowlevel operators，对于数据库的lib库接口，后续可以在此基础上再做一层对接。lowlevel operators接口一共45个，如下：

7/33设计文档规范 设计文档需要具备以下内容：  修订记录  审批记录  系统介绍  相关调研  架构  重要流程  关键算法  接口  数据库设计  非功能特性设计  参考文献 8/33代码编写规范 Curve代码编写规范遵循Google Style Guides（https://google.github.io/styleguide/） 9/33新代码提交 Dailybuild测试

CurveFS空间分配调研#bluestore chubaofs: CurveFS空间分配调研#chubaofs moosefs: moosefs空间分配调研 polarfs: CurveFS文件存储设计参考方案（元数据存储在卷上方案）#PolarFS 上述fs可以分为两类 chubaofs/moosefs 属于利用本地文件系统去构建分布式fs。一个文件的数据对应本地文件系统上的一个文件，通过本地文件系统的打洞功能实现部分空间的回收。