主要目的是验证gfs的存储策略，是否是只考虑hash的结果，还是考虑机器的负载。
测试方案：
先在建一个volume，添加几个brick（几个brick不在同一台机器），然后存放一些文件，文件大小在1G左右，然后添加一个brick，这个brick与其他也不在同一个机器（虚拟机也可以），然后连续存储几个几百M的文件，看是否将这几个文件分布到新加的空brick还是随机分布在所有的brick。@李乾坤(kevinli)
-
李乾坤 8年前
测试环境：虚拟机四台，2G内存，40G硬盘空间
测试结果：
添加brick前：
三个brick，数据卷类型为distributed，文件大小总为1.1G，包含三个二级子目录和众多三级子目录。
将文件（1.2G）存放进volume，文件在各个brick的分布大小（du -h）情况如下：
Brick
Brick1
Brick2
Brick3
大小
409M
292M
466M
添加brick，成功。
第一次文件添加（330M）
Brick
Brick1
Brick2
Brick3
Brick4
大小
+52M（461M）
+172M（464M）
+89M（555M）
43M
第二次文件添加（248M）
Brick
Brick1
Brick2
Brick3
Brick4
大小
+8K（461M）
+57M（521M）
+179M（734M）
+14M（57M)
第三次添加文件（513M）
Brick
Brick1
Brick2
Brick3
Brick4
大小
+117M（578M）
+171M（638M）
+112M（846M）
+237（251M）
从以上测试结果可以看出，对于新增加的brick，glusterfs并没有特别对待，而是看做和旧的brick一样进行数据分配。这一测试是在分布巻下进行，在副本卷、切片卷下，之前的测试也表明，gkusterfs不会有特殊操作来区分新旧brick。
- 当前状态 新增
- 选定优先级 正常
- 指派给 李乾坤
- 里程碑 --
- 开始日期 09/28/2016
- 结束日期
- 预计工时(H) 0.00 hour
- 完成度 0%
- 关联Commit 无
