关于moosefs，我的看法

bbjmmj

先说性能，实测，小规模应用，它的性能不如GLUSTERFS2.0。MFS的排序使用的是HASH排序，64位CHUNK号HASH成16位，HASH号相同的组成一个不定长的链表，用来存储CHUNK的信息。这种排序要命的地方是它必须得保证所有CHUNK索引都得放在MASTER服务器的内存中，如果存储在磁盘上，MASTER的效率会非常低下，低下到你忍受不了的程度。因为服务器内存容量一般都相当有限，这种排序方法也就决定了MFS不可能管理太多的文件，除非它能改成B树排序。
   MFS对内存容量的要求非常大，一般的服务器也就几G的内存，PB级的存储，可能要消耗1TB的内存（跟文件数量有关），有点离谱了。
   MFS对超过64M大小的文件会进行切割，这种切割跟GOOGLE的GFS是一样的，可以说MFS跟GFS结构和原理上都很相像，区别是MFS支持POSIX，而GFS则不支持POSIX，对于NAS一类需要POSIX支持的应用，GFS、KFS、HDFS、MogileFS等等都是不能用的，而MFS则可以，但是MFS同时肯定也得付出性能代价。
   MFS支持类似WINDOWS回收站的功能，前面提到的文件系统都没有这个功能，如果误删了文件，可以从回收站里再MV回来。对POSIX的支持和回收站功能，使得MFS特别适合做NAS存储。
   MFS的MASTER不是分布式的，一套MFS的存储系统里面只能有一个MASTER，MASTER挂了存储集群就没法工作了。除了可靠性的问题外，非分布式的MASTER也限制了MFS文件系统的性能。
   MFS的CHUNK SERVER并不是挂上去就能自动同步的，得find "mount目录" *它才会进行同步，所以你不能一次更换太多的CHUNK SERVER，这样做有丢数据的可能。
   目前版本的MFS还不完全适合做NAS，因为不支持磁盘配额，上线后单位员工滥用空间你可就死定了，等1.7版吧。不过我已经放弃它了，等CEPH吧，反正也不急着用

bbjmmj

1.MFS 排序用来干嘛的？ 所有chunk 索引都放在内存中？
2.MFS MFS对内存容量要求非常大， PB级别的，要消耗 ...
peidright 发表于 2010-07-17 10:11

    1、有点类似在多个硬盘上找某一个文件，文件位置的索引就是LINUX的目录文件，当目录较多，且深度较大时，查找文件就会相当耗时。MFS的做法相当于把所有目录结构都事先读到内存里去，进行HASH排序，虽然排序后索引深度增加，但因为都是在内存里，速度可以比存储在硬盘上快得多。大概就是这么个意思。
   2、MFS对内存容量的需求我曾经用我自己的土办法做过估算，我怀疑我的估算是错误的，因为没人去做这个估算，所以我就假定我估算的结果是错的，然后我去打听一些稍大型的生产系统，几十TB容量的，得到的结果却跟我用土办法估算出来的结果一样，于是大概推算出对于WEB类型的应用，1PB的MFS存储，MATASERVER大概需要1TB内存。我的测试办法是改变MFS文件系统文件数量，然后观察内存占用的变化，做测试用了上百万个文件。当然，科学的做法应该是对源码进行分析。

bbjmmj

回复 4# peidright


    第一点是根基问题，大问题啊，现在的分布式文件系统，检索都用B树了。B树是可以存到硬盘上的，因为遍历深度相当有限。比如说10亿个文件，如果用B树的话，遍历深度大约是30，而如果用MFS的HASH树，平均遍历深度将达到10亿/65536。
   关于第二点，NAS上存储的文件，平均大小远低于32M，连1M都不到。MFS比较适合存一些大的文件，大表、什么的。

bbjmmj

回复 6# peidright


    B树是二叉树。

bbjmmj

回复  bbjmmj


    bbjmmj 去死吧，不要在这里误人子弟了，Btree是二叉树，你眼里只有二叉树吗？
一直 ...
michaelrun 发表于 2010-07-24 19:28

    B树不管有几个叉，都是二叉树
    如果你非要较真不可，牛顿定律都是错的，如果你非要较真不可，任何长度的测量结果就都不能使用了。MFS的HASH排序，确实存在遍历深度过大的问题，效率也低，这个结论没有错就可以了。