我现在有海量的数据文件(1000万个文件)需要存储，需要让其他计算机可以很容易地访问，数据无价，我还希望这个文件系统带冗余功能。
我首先注意到的是Ubuntu Enterprise Cloud的提供者:Eucalyptus。它提供了和AWS(Amazon Web Service)几乎完全兼容的云计算接口。看起来似乎是个云存储的靠谱解决方案。
Eucalyptus模仿Amazon的S3服务，提供了一个叫做Walrus的存储服务组件。
可是，经过一番探索，我发现Eucalyptus想说爱你不容易。
一方面是因为Eucalyptus配置起来很麻烦，缺乏文档，网上几乎找不到任何相关帮助，
另一方面，虽然理论上Eucalyptus和AWS的EC2/S3兼容，但实际上并非如此，很多在AWS上可以用的工具，在Eucalyptus上就无法使用
最关键是，直到最后我把Walrus配置完成之后，才发现Walrus根本不像我想的那样，是一个带冗余的云存储系统。而只是一个实现了S3接口的单机软件而已。
实际上Walrus和Eucalyptus的另一个组件sc(storage controller)没有任何关联，Walrus只是提供了和S3一致的接口，而它的实现方式，既不带冗余，也不能分开部署在多台服务器上。
于是我开始寻找一个真正的分布式文件系统，来解决我的存储难题。一找才发现，市面上各种分布式文件系统品种繁多，层出不穷。列举几个主要的：
mogileFS：Key-Value型元文件系统，不支持FUSE，应用程序访问它时需要API，主要用在web领域处理海量小图片，效率相比mooseFS高很多。
fastDFS：国人在mogileFS的基础上进行改进的key-value型文件系统，同样不支持FUSE，提供比mogileFS更好的性能。
mooseFS：支持FUSE，相对比较轻量级，对master服务器有单点依赖，用perl编写，性能相对较差，国内用的人比较多
glusterFS：支持FUSE，比mooseFS庞大
ceph：支持FUSE，客户端已经进入了linux-2.6.34内核，也就是说可以像ext3/rasierFS一样，选择ceph为文件系统。彻底的分布式，没有单点依赖，用C编写，性能较好。基于不成熟的btrfs，其本身也非常不成熟。
lustre：Oracle公司的企业级产品，非常庞大，对内核和ext3深度依赖
NFS：老牌网络文件系统，具体不了解，反正NFS最近几年没发展，肯定不能用。
本来我打算用mogileFS，因为它用的人最多，而且我的主要需求都是在web方面。
但是研究了它的api之后发现，Key-Value型文件系统没有目录结构，导致不能用list某个子目录的所有文件，不能直接像本地文件系统一样操作，干什么事情都需要一个api，让人十分不爽。
mogileFs这种做法，可能是受同一个开发团队的另一个大名鼎鼎的产品memcached的侦听端口+api模式影响，也有可能是mogileFS刚开始设计的时候，FUSE还没有开始流行。
总之我决心要找一个支持FUSE的分布式文件系统，最后就在mooseFS, glusterFS, ceph中选择。从技术上来看，ceph肯定是最棒的，用c编写，进入linux-2.6.34内核，基于btrfs文件系统，保证了它的高性能，而多台master的结构彻底解决了单点依赖问题，从而实现了高可用。可是ceph太不成熟了，它基于的btrfs本身就不成熟，它的官方网站上也明确指出不要把ceph用在生产环境中。
而且国内用的人较少，linux发行版中，ubuntu10.04的内核版本是2.6.32，仍然不能直接使用ceph。
而glusterFS比较适合大型应用，口碑相对较差，因此也不考虑。
最后我选择了缺点和优点同样明显的mooseFS。虽然它有单点依赖，它的master非常占内存。但是根据我的需求，mooseFS已经足够满足我的存储需求。国内mooseFS的人比较多，并且有很多人用在了生产环境，更加坚定了我的选择。
打算用一台高性能服务器(双路至强5500, 24GB内存)作为为master，两台HP DL360G4(6块SCSI 146GB)作为chunk服务器，搭建一个冗余度为2的分布式文件系统，提供给web服务中的每一台服务器使用。
本文转自沈二铺子博客，原文链接：流行的开源分布式文件系统比较