分布式并行容错文件系统

如果是我，我会使用GlusterFS。 目前的版本非常稳定，而且我知道在HPC和Internet空间中的某些非常大型的安装中，人们依赖于它们的生产系统。 你可以基本上根据你的需要量身定做，通过按需要布置组件。 与Lustre不同的是，没有专门的元数据服务器，所以中心的故障点最小化，并且更容易扩展设置。

不幸的是，我不认为有一个简单的方法可以达到你的75％的标准，而不会让性能下降。

它在商品硬件上运行，但是在使用Infiniband互连时性能确实很好。 幸好现在IB的价格真的很低。

您可能想要查看Scalable Informatics和他们的Jackrabbit产品的解决scheme。 他们在他们的硬件上支持GlusterFS，他们的解决scheme的价格肯定会对抗从头开始组装的成本。

其实我觉得没有那么多现实的select。 按照优先顺序我的select是：

1. 亚马逊S3 。 满足您的所有要求，以及您的可选品质。 有很好的正常运行时间和支持logging。 它不是内部的; 但这真的不是一个需要你可以解决，fx使用VPN访问或只是很好的旧HTTPS … 如果广域网延迟和亚马逊定价为您工作，S3真的是我的第一select。 如果定价不适合你，那么我怀疑一个DYI解决scheme最终会大大降低成本…
2. MogileFS似乎完全符合您的要求。 MogileFS没有太多的活动，但主要是因为它正在为（相对较less的）用户使用。
3. Lustre拥有非常棒的技术 ，是一个普通的本地POSIX文件系统（如果这对你有好处），并且多年来一直在不断更新。 最大的问题是整个太阳 – 甲骨文合并是否会影响Lustre。 长期来看，如果Sun正确地使用卡片，那么ZFS和Lustre在同一屋檐下可能会导致非常好的事情……现在，我认为Lustre主要用于学术和商业HPC计划，而不是在互联网应用程序 -这可能是不真实的，但是如果Lustre在互联网应用中performance不错，那么他们肯定不会把这个事实做好。

Hadoop分布式文件系统（HDFS）不符合你的要求恕我直言。 HDFS非常棒，但是它的类似bigtable的方法意味着它比上面的文件系统更不易访问。 当然，如果你真的想要大规模的可扩展性和长远的眼光，HDFS可能是正确的 – 雅虎，Facebook和其他公司都在投资Hadoop的增长。

一个评论，大多数上述系统将整个文件复制到2-3个节点以实现冗余。 这比奇偶校验编码/ RAIDscheme占用了更多的空间，但它可以大规模地处理，而且似乎是每个人都采取的解决scheme。 所以你不会得到你提到的75％的效率…

它可能不能满足你所​​有的要求，特别是空间效率（默认情况下，它将每块分成10份，其中3份可以提供恢复（尽pipe这可以调整）），但你仍然可能想看看塔霍-LAFS 。

它主要是为备份而devise的，但是人们已经构build了（并且仍然在构build）很多非常有趣的非备份应用程序。 例如，其中一位开发人员在他的博客上。

GPL，用Python编写。 它已经包含在Ubuntu，IIRC中。

作为对Kamil响应的补充，您可以通过尝试从GFS-AFAIK上的每个文件中读取来强制存储节点发生故障之后在GlusterFS中强制执行数据复制，而没有更简单的方法来确定哪些文件需要复制。

下面的命令可以帮助 – 它实际上在每个文件上调用head -c1并将成功/失败logging到/tmp/gfs-check.log

 find /mnt/gfs ! -type d \( \( -exec head -qc1 '{}' + \ -fprintf /tmp/gfs-check.log "%p OK\n" \) -o \ -fprintf /tmp/gfs-check.log "%p ERROR\n" \) > /dev/null