unk内部会划分为多个block，每个block最大4M，每个block对应s3上一个object。 s3上对象已chunkid_indexblock_version进行命名，元数据则已S3ChunkInfo（见数据结构）的方式存储在inode中。对于文件顺序写场景，文件0~4M的s3对象必然为chunkid_0_0_4M~8M为chunkid_1_0，以此类推，还有一种情况是文件先写了0~2M $ \{2,0,0,8M\} $ 。对于覆盖写，为了区分新老数据，则会对version进行 $ ++ $ ，比如覆盖写了0~4M，则数据会写到chunkid_0_1的对象，则元数据包含了2个S3Chunkinfo $ \{2,0,0,8M\} $ 和 $ \{2,1,0,4M\} $ 。 ## 接口和关键数据结构 common.proto enum FSType { TYPE_VOLUME TYPE_DIRECTORY = 1; TYPE_FILE = 2; TYPE_SYM_LINK = 3; TYPE_S3 = 4; }; // inodes3chunk message S3ChunkInfo { required uint64 chunkId = 1; required uint64 version = 2; required uint64 offset

原则是尽力而为，并不能做到完美 ## 方案 基于一下3个基础的数据结构，2层索引 基于以下3个基础的数据结构，2层索引 s3chuninfolist[index] = [s3chunkinfo(s)] s3chunkinfo { chunkid version // write always 0, compact will increase it offset len } s3 object

算|256| |sizeof(inode)|112| |sizeof(volumeExtentList)|48| |sizeof(S3ChunkInfoList)|48| |sizeof(S3ChunkInfo)|64| |sizeof(VolumeExtent)|56| dentry大小： 空的dentry占用56B; 最大的dentry占用字节56 + 256 = 312 B; inode大小: 按照最差的情况，文件里面全部都是碎片，那么metaserver上的空间碎片将会占用最多的空间。这里忽略掉其他次要的因素，考虑全是空间碎片信息，每条记录只保存4KB数据，可以保存多少元数据。选取占用空间更多的S3ChunkInfo。按照一台metaserver 256GB内存容量全部用来保存空间分配计算。可以的保存chunkinfo条数=256GB/64B=4G。可以保存的文件的大小为4G*4KB=64TB的空间。i

本地磁盘缓存 如果有配置writeBack dev，则会调用diskStroage进行本地磁盘write，最终写到s3则由diskStroage模块决定。 关键数据结构 message S3ChunkInfo { required uint64 chunkId = 1; required uint64 compaction = 2; required uint64 offset