含有一系列的扩展属性。每一个属性由一个名字以及与之相关联的数据所表示。其中名字必须为一个 字符串 ，并且必须有一个 命名空间 前缀标识符与一个点字符。目前存在有四种命名空间：用户命名空间、信任命名空间、安全命名空间以及系统命名空间。用户命名空间在命名或者内容上没有任何限制。系统命名空间主要被内核用于访问控制表上 。目前Linux 的 ACL 存储实现就是基于这种扩展属性的。 Inode Table中保存有若干个

时仍需要更改元数据，存在一定的IO放大。 解决思路： 直接使用覆盖写过一遍的文件。由于chunk大小固定，预先生成一批被写过的固定大小文件。创建 chunk文件或快照文件时直接从预分配的文件池中获取进行重命名，删除chunk时再将文件重命名放到 预分配池中，这个预分配池就是chunkfile pool。 进一步优化： 对chunk写0 -> nvme的write zeroCurve介绍 01 02 raft和braft

BaseName； • Value：自身的文件ID。 这种方式可以很好地平衡几个需求： • 文件列目录：列出目录下的所有文件和目 录 • 文件查找：查找一个具体的文件 • 目录重命名：对一个目录/文件进行重命名 当前元数据信息编码之后存储在 etcd 中。COPYSET Curve系统中数据分片的最小单位称之为Chunk。在大规模的存储容量下，会产生大量的Chunk，如此众多的 Chu

chunkid version // write always 0, compact will increase it offset len } s3 object命名: chunkid_version_index (index为obj在chunk内的index) 执行步骤 数据整理作为一个后台服务(线程池), 运行于metaserver, 遍历meta

待定），chunk内部会划分为多个block，每个block最大4M，每个block对应s3上一个object。 s3上对象已chunkid_indexblock_version进行命名，元数据则已S3ChunkInfo（见数据结构）的方式存储在inode中。对于文件顺序写场景，文件0~4M的s3对象必然为chunkid_0_0,4M~8M为chunkid_1_0，以此类推， 还有

的文件，称为SnapFile和ChunkFile；  SnapFile 与ChunkFile是同构的,都 来自ChunkFilePool；  SnapFile与ChunkFile在同一个目录；  SnapFile的命名方式为“chunk_” + ChunkId + “_snap_”+ seqNum的形式，以区别于 ChunkFile。CHUNKSERVER端快照实现-SNAPFILE 字段 类型 说明 version

和混沌测试，确保master分支代码的 bug尽可能早地暴露出来。 通过这种流程，curve可以在一定 程度上保证master分支的稳定性。 master 10/33版本管理 Curve版本命名规则是x.y.z{-后缀}  x为主版本号，每次发布大版本时递增； 大版本一般半年发布一次。  y为次版本号，每次发布小版本时递增; 小版本一般1~2个月发布一次。  z为修订号，修复一批bug后递增。