© XXX Page 1 of 12 元数据持久化© XXX Page 2 of 12 前言 Raft Log Raft Snapshot 持久化文件 key_value_pairs 其他说明 实现 1、inode、entry 的编码 2、KVStore Q&A 单靠 redis 的 AOF 机制能否保证数据不丢失? redis 的高可用、高可扩方案？ redis + muliraft 前言 根据之前讨论的结果，元数据节点的架构如下图所示，这里涉及到两部分需要持久化/编码的内容： Raft Log：记录 operator log Raft Snapshot：将内存中的数据结构以特定格式 dump 到文件进行持久化© XXX Page 3 of 12 Raft Log +------+------------+-----+----------------+---------+----------+ message); private: map Hash; // B+ std::string filePtah; // WAL dump (WAL : curvefs.waldump : curvefs.dump) }; Q&A© XXX Page 9 of 12 单靠 redis 的 AOF 机制能否保证数据不丢失? 不能，因为

→ hashtable(inode id) fsedge → hashtable (parent inode + name) 全内存 chunk → hashtable(chunk id) log + dump record 差 否 chunk 链式多副本 overwirte有数据不一致风险 chubaofs（cfs） 有元数据服务器 inode → b tree(key ino) dentry 内部结点不保存数据，只有叶子结点保存数据。 https://github.com/begeekmyfriend/bplustree，（MIT），实现了落 盘 BST O(log(n)) O(n) c++ stl 模板© XXX Page 4 of 24 skip list O(log(n)) O(n) level db，https://github.com/google/leveldb/blob/master/db/skip 。 如果采用raft的方式对元数据持久化进行保证，所有元数据的处理都是先写WAL，再修改内存结构。那么任何对元数据的增删改查，对应着一条记录，根据记录去修改内存数据。 按照之前的讨论，curve文件系统的元数据管理采取先写log的方式。这里先不考虑log的组成形式。 那么curve文件系统的应该是先写log，log落盘之后，更新内存。 场景三：系统退出的时候，元数据的持久化 如果采

一个复制组可以包含多个文件的元数据信息 复制组 wal 记录元数据操作 定期 snapshot 对 wal 进行清理。snapshot 中存储的是键值对，其中 inode 文件中存储 inode-inodeInfo; dentry 中存储 filename-dentryInfo 信息 copyset 启动的时候根据 inode 和 dentry 分别建立对应的内存结构，再回放 wal 日志完成构建 卷的元数据管理

the protocol (read-only) */ unsigned proto_minor; /** * Maximum size of the write buffer */ unsigned max_write; /** * Maximum size of read requests. A value of zero indicates no * limit. two types of requests fall into this category: * * 1. Read-ahead requests * 2. Asynchronous direct I/O requests * * Read-ahead requests are generated (if max_readahead is * non-zero) by the the kernel's * flusher algorithm), regular (i.e., synchronous and * buffered) userspace read/write requests (limited to one per * thread), asynchronous read requests (Linux's io_submit(2) * call

Provides read and write data interfaces for upper-layer applications l Interacts with MDS to add, delete, modify, and query metadata l Interacts with the chunkServer to read and write data 4. Snapshotcloneserver scattered all over the storage nodes. ChunkServer provides 4KB random read/write capability to support 4KB aligned read/write on block devices.CurveBS file structure of virtual block device As mentioned CurveBS. A CopySet contains multiple chunks. Copysets in CurveBS are created in advance. When users write data, they only need to select an appropriate CopySet and create a new chunk. Why use a CopySet

~DiskCacheManagerImpl() { TrimStop(); } int Init(const std::string cacheDir); int Write(std::string name, const char* buf, uint64_t length); int Read(std::string name, char* buf, uint64_t fileName, const char* buf, uint64_t length);© XXX Page 6 of 9 /** * @brief Create Disk Write Cache Dir. */ int CreateDir(const std::string cacheDir); bool IsDirExist(const std::string = 1024*4; LOG(INFO) << "whs start write."; for(int i = 0; i < 100000; i++) { char str[5]; sprintf(str, " %d" , i); Write(str, buf, length); } LOG(INFO) << "whs

$ ETCDCTL_API=3 ./bin/etcdctl get foo --write-out=json revision: 2 $ ETCDCTL_API=3 ./bin/etcdctl put foo bar $ ETCDCTL_API=3 ./bin/etcdctl get foo --write-out=json revision: 3 $ ETCDCTL_API=3 ./bin/etcdctl /bin/etcdctl put hello world $ ETCDCTL_API=3 ./bin/etcdctl get foo --write-out=json revision: 4 $ ETCDCTL_API=3 ./bin/etcdctl get hello --write-out=json revision: 4 $ ETCDCTL_API=3 ./bin/etcdctl put hello hello world $ ETCDCTL_API=3 ./bin/etcdctl get hello --write-out=json revision: 5 3.2.2 举例说明Campagin流程 场景描述：三个mds(mds1, mds2, mds3)，希望实现一个mds作为主提供服务，另外两个mds作为备在主挂掉的时候提供服务的功能。如果利用上述的Campagin进行选举，过程如下： 正常情况：

open系统调用会打开pathname指定的文件（如果不存在，如果携带O_CREAT flag则会创建），返回一个文件描述符fd（该fd是进程打开文件描述符表的index），在后续系统调用（read(2)、write(2)、lseek(2)、fcntl(2) etc.）中指向这个打开的文件。打开的文件描述符记录中保存着文件的offset 和 文件status。 每个进程都有个 task_struct 描述符用来描述进程相关的信息，其中有个 输入都将会影响用户的进程。 O_NOCTTY : 如果文件存在，且是个普通文件，具有对该文件的写权限，该flag会将文件长度截断为0。 O_TRUNC : 追加写，每次write都会将file offset 指向文件尾（file offset的修改和write操作在一个原子操作中完成）。 O_APPEND O_NONBLOCK O_NDELAY: O_NONBLOCK和O_NDELAY所产生的结果都是使I 0，这样无法区分是哪种情况。因此O_NONBLOCK就产生出来，它在读取不到数据时会回传-1，并且设置errno为EAGAIN。 : 每次write都等到物理I/O完成，包括write引起的文件属性的更新。 O_SYNC O_DSYNC: 每次write都等待物理I/O完成，但是如果写操作不影响读取刚写入的数据，则不等待文件属性更新（在linux 2.6.33之前只有O_SYNC flag，

ChunkServer。 2. ChunkServer 收到请求，将请求封装成一个 log entry，提交给 raft。 3. raft模块在本地持久化 entry 的同时发送 entry 给其 他副本（ChunkServer）。 4. 本地持久化 log entry 成功，且另一个副本也写入 log entry 成功则 commit。 5. commit 后执行 apply，apply 03 raft在Curve中的应用 05 Q&A 04 Curve对raft的优化Curve对RAFT的优化 优化点一：轻量级快照 问题背景： raft的快照需要定期打快照，用来清理log。对于Curve块存储场景，系统状态就是Chunk当前的数据。 如果把所有chunk 拷贝一遍打快照，会出现两个问题： 1. 每次快照，空间上要多出1倍，空间浪费严重。 2. Curve块存储快照间隔默认30 chunk文件或快照文件时直接从预分配的文件池中获取进行重命名，删除chunk时再将文件重命名放到 预分配池中，这个预分配池就是chunkfile pool。 进一步优化： 对chunk写0 -> nvme的write zeroCurve介绍 01 02 raft和braft 03 raft在Curve中的应用 05 Q&A 04 Curve对raft的优化Q&A • 主页：https://opencurve

2021/8/18 胡遥 初稿 背景 整体设计 元数据采用2层索引 对象名设计 读写缓存分离 缓存层级 对外接口 后台刷数据线程 本地磁盘缓存 关键数据结构 详细设计 Write流程 Read流程 ReleaseCache流程 Flush流程 FsSync流程 后台流程 poc测试验证 背景 基于s3的daemon版本基于基本的性能测试发现性能非常差。具体数据如下： 4层，通过inodeId找到file，通过index找到chunk，然后通过offset~len找到是否有合适的datacache或者new datacache。 对外接口 流程上对于读写缓存有影响的接口包括：write，read，releaseCache，flush，fssync。后面会详细介绍这些接口流程。这里不需要提供truncate接口，可以由client直接修改inode的len，由metaserver的碎片整 启动后台线程，将写Cache定时刷到S3上，同时通过inodeManager更新inode缓存中的s3InfoList。具体细节见 本地磁盘缓存 如果有配置writeBack dev，则会调用diskStroage进行本地磁盘write，最终写到s3则由diskStroage模块决定。 关键数据结构 message S3ChunkInfo { required uint64 chunkId = 1; required