9. 实际操作案例
9.1 默认的垃圾回收时间是86400，存在一种可能性是垃圾还没回收完，你的存储容量就暴掉了。（案例提供者shinelian）
方案1：设置垃圾回收时间，积极监控存储容量。
经过测试，把垃圾回收时间设置300秒，完全可以正确回收容量。
方案2：手动周期性去删除metamfs里的trash目录下的文件（健壮性还有待测试，反正删除后容量是回收了，不晓得有没有什么后遗症。）
经过测试，貌似没后遗症，有后遗症的同学请在qq群里面联系我。
9.2 mfs 1.6.x的User Guides和FAQ，并和灵犀沟通对文档中不理解的地方，就理解不一致的地方达成一致。MFS1.6.x比1.5.x中有以下的变化：(特别感谢qq群内网友 流云风 和 灵犀 )
（1）修复1.5.x中在大批量操作时打开文件过多的bug。这个错误也在我们此次测试的时候遇到，报的错误说是打开的文件过多，造成
chunker
server的链接错误。虽然后来的测试中一直想模拟出来这个问题，但是一直无法模拟出来。在1.6.x中解决此问题，就解决了很大的问题。
（2）新增加了masterlogger服务器。这是在1.5.x中所没有的，就是做了master服务器的冗余，进一步的加强的master服务器的稳定性。在mfs体系中master是要求最稳定以及性能要求最高的，因此务必保证master的稳定。
（3）修改1.5.x中存在的对于坏块的修复功能。在mfs1.5.x中遇到chunker坏块校验，错误比较多的是很往往导致master将出现坏块
的chunker自动的剔除出去的情况，此次增加了对坏块的修复功能，很方便的进行修复，简化对坏块的处理功能。
（4）对metadata和changelog的新认识。之前认为changelog记录的是文件的操作，定期的像数据库的日志一样归档到
metadata中。发现上面的理解存在误区，真正的是changelog中记录了对文件的操作，metadata记录文件的大小和位置。因此
metadata是比较重要的，在进行修复的过程中是采用metadata和最后一次的changelog进行修复的。
（5）MFS文档中明确指出对于内存和磁盘大小的要求。【In our environment (ca. 500 TiB, 25
million files, 2 million folders distributed on 26 million chunks on 70
machines) the usage of chunkserver CPU (by constant file transfer) is
about 15-20% and chunkserver RAM usually consumes about 100MiB
(independent of amount of data).
The master server consumes about 30% of CPU (ca. 1500 operations per
second) and 8GiB RAM. CPU load depends on amount of operations and RAM
on number of files and folders.】
（6）指出了在测试的过程中多个chunker并不影响写的速度，但是能加快读的速度。在原来的基础上增加一个chunker时，数据会自动同步到新增的chunker上以达到数据的平衡和均衡。
9.3 mfs1.5.x 数据恢复实例 （案例分享 ： QQ群战友 Xufeng）
其实很简单，就是mfsrestore, 然后启动服务的时候，并有任何提示信息，进程启不来,其实是配置文件放PID的目录会被删掉，重建这个目录，然后赋予权限就可以了,我已经做过1.5到1.6的升级，还可以.
详情见 Xufeng blog http://snipt.net/iamacnhero/tag/moosefs
10. 生产环境案例（大家踊跃提供，不断更新中~~~~~~）
http://www.gaokaochina.com 田逸