Curve 文件存储随着存量数据增长

Curve 文件系统的重要特点之一就是适用于海量文件存储，那么 Curve 文件系统如何保证可以支撑百亿级规模？如何保证在百亿级规模下的性能？从理论上来看：

• 规模方面，Curve 文件存储的元数据集群，每个节点存储一定范围的 inode (比如 1~10000) 和 dentry，如果文件数量增多，可以进行存储节点的扩充，所以理论上规模是没有上限的。

• 性能方面，当文件数量很多时，对于单个文件的操作是没有什么差别的，但对于一些需要元数据的聚合操作会出现性能问题，比如 du (计算当前文件系统的容量), ls (获取目录下所有文件信息) 等操作，需要做一定的优化来保障性能。

那实际上 Curve 文件系统的表现如何呢？

首先介绍一下文件系统的几款通用测试工具。

1. pjdfstest[1]: posix 兼容性测试。有 3600 + 个回归测试用例，覆盖 chmod, chown, link, mkdir, mkfifo, open, rename, rmdir, symlink, truncate, unlink 等

2. mdtest[2]: 元数据性能测试。对文件或者目录进行 open/stat/close 等操作，并返回报告

3. vdbench[3]: 数据一致性测试。Vdbench 是 Oracle 编写的一款应用广泛的存储性能测试工具，既支持块设备的性能测试，也支持文件系统性能测试，在做随机写的一致性测试很方便，能实时检查出哪一个扇区出现了数据不一致

4. fio[4]: 数据性能测试。

Curve 文件系统从 v2.3 版本以后提供了单独压测元数据集群的方式（数据集群一般使用 Curve 块存储和 S3 ，所以直接对这些组件进行性能测试即可）。

1. 通过 CurveAdm[5] 搭建文件系统，在准备客户端配置文件 client.yaml[6] 时新增配置项: s3.fakeS3=true[7]。

2. 使用 mdtest，vdbench，ImageNet 数据集 [8] 作为数据源，测试大小文件混合场景下文件系统的稳定性和性能。

根据元数据的数据结构估算，百亿级文件的存储元数据逻辑空间大概需要 8TB，实际存储使用 3 副本大概在 24TB 左右。有兴趣测试的小伙伴可以参考一下。

海量文件存储下性能如何

Curve 文件存储随着存量数据增长，性能可以相对保持平稳（stat 请求的下降在 15% 左右）。

场景 1 (测试目录个数较多的情况):

测试命令 mdtest -z 2 -b 3 -I 10000 -d /mountpoint

场景 2 (测试目录层级很深的情况): 

测试命令 mdtest -z 10 -b 2 -I 100 -d /mountpoint