分布式文件系统分布式文件系统MooseFSMogileFSGlusterFSGFS2OCFS2OpenAFS/CodaCephLustrePVFS2CodaHadoop HDFSFastDFSNFSdCachextreemfsCloudStore (KosmosFS)NFSv4 ReferralsNFSv4.1 pNFSspNFSGFarm

62 阅读 0 评论 41 点赞

我是靠谱客的博主彩色跳跳糖，最近开发中收集的这篇文章主要介绍分布式文件系统分布式文件系统MooseFSMogileFSGlusterFSGFS2OCFS2OpenAFS/CodaCephLustrePVFS2CodaHadoop HDFSFastDFSNFSdCachextreemfsCloudStore (KosmosFS)NFSv4 ReferralsNFSv4.1 pNFSspNFSGFarm，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

分布式文件系统

相对于本机端的文件系统而言，分布式文件系统（英语：Distributed file system, DFS），或是网络文件系统（英语：Network File System），是一种允许文件通过网络在多台主机上分享的文件系统，可让多机器上的多用户分享文件和存储空间。在这样的文件系统中，客户端并非直接访问底层的数据存储区块，而是通过网络，以特定的通信协议和服务器沟通。借由通信协议的设计，可以让客户端和服务器端都能根据访问控制清单或是授权，来限制对于文件系统的访问。相对地，在一个分享的磁盘文件系统（英语：shared disk file system）中，所有节点对数据存储区块都有相同的访问权，在这样的系统中，访问权限就必须由客户端程序来控制。分布式文件系统可能包含的功能有：透通的数据复制（英语：replication (computer science)）与容错（英语：fault tolerance）。也就是说，即使系统中有一小部分的节点离线，整体来说系统仍然可以持续运作而不会有数据损失（英语：data loss）。分布式文件系统和分布式数据存储的界线是模糊的，但一般来说，分布式文件系统是被设计用在局域网，比较强调的是传统文件系统概念的延伸，并通过软件方法来达成容错。而分布式数据存储，则是泛指应用分布式运算技术的文件和数据库等提供数据存储服务的系统。

分布式系统（distributed system）是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。内聚性是指每一个数据库分布节点高度自治，有本地的数据库管理系统。透明性是指每一个数据库分布节点对用户的应用来说都是透明的，看不出是本地还是远程。在分布式数据库系统中，用户感觉不到数据是分布的，即用户不须知道关系是否分割、有无副本、数据存于哪个站点以及事务在哪个站点上执行等。

传统纸笔——>磁盘磁带光盘——>单机时代——>独立文件服务器——>存储服务器/设备——>分布式文件系统-->未来量子通信

专业测评

常见的分布式文件系统有，GFS、HDFS、Lustre 、Ceph 、GridFS 、mogileFS、TFS、FastDFS等。各自适用于不同的领域。它们都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务。

分布式软件系统(Distributed Software Systems)是支持分布式处理的软件系统,是在由通信网络互联的多处理机体系结构上执行任务的系统。它包括分布式操作系统、分布式程序设计语言及其编译(解释)系统、分布式文件系统和分布式数据库系统等。

分布式操作系统

负责管理分布式处理系统资源和控制分布式程序运行。它和集中式操作系统的区别在于资源管理、进程通信和系统结构等方面。

分布式程序设计语言

用于编写运行于分布式计算机系统上的分布式程序。一个分布式程序由若干个可以独立执行的程序模块组成，它们分布于一个分布式处理系统的多台计算机上被同时执行。它与集中式的程序设计语言相比有三个特点：分布性、通信性和稳健性。

分布式文件系统

具有执行远程文件存取的能力,并以透明方式对分布在网络上的文件进行管理和存取。

分布式数据库系统

由分布于多个计算机结点上的若干个数据库系统组成,它提供有效的存取手段来操纵这些结点上的子数据库。分布式数据库在使用上可视为一个完整的数据库,而实际上它是分布在地理分散的各个结点上。当然,分布在各个结点上的子数据库在逻辑上是相关的。

分布式邮件系统

分布式邮件系统的部署设计，即同一域名下，跨地域部署的邮件系统。适用于在各地设有分部的政府机构或者大型集团，有效管理各地的人员结构，同时提高了邮件服务器应用效率。

分布式邮件系统由多个数据中心组成，大量分支机构或较小的分散站点与数据中心的连接。分支机构需要建立自己的邮件服务器，来加快处理当地分支机构的邮件。承载相应的数据处理量。以提高邮件处理能力，邮件收发速度，邮件功能模块化。

名词解释

网络文件系统

早期的unix和nethud也是一种网络操作系统，网络操作系统和网络文件系统是一种包含关系。

(NFS) 最早由Sun微系统公司作为TCP/IP网上的文件共享系统开发。Sun公司估计现在大约有超过310万个系统在运行NFS，大到大型计算机、小至PC机，其中至少有80%的系统是非Sun平台。

Andrew文件系统

(AFS) 结构与NFS相似，由卡内基·梅隆大学信息技术中心(ITC)开发、现由前ITC职员组成的Transarc公司负责开发和销售。AFS较NFS有所增强。

分布式文件系统

(DFS) 是AFS的一个版本，作为开放软件基金会(OSF)的分布式计算环境(DCE)中的文件系统部分。

如果文件的访问仅限于一个用户，那么分布式文件系统就很容易实现。可惜的是，在许多网络环境中这种限制是不现实的，必须采取并发控制来实现文件的多用户访问，表现为如下几个形式：

只读共享任何客户机只能访问文件，而不能修改它，这实现起来很简单。

受控写操作采用这种方法，可有多个用户打开一个文件，但只有一个用户进行写修改。而该用户所作的修改并不一定出现在其它已打开此文件的用户的屏幕上。

并发写操作这种方法允许多个用户同时读写一个文件。但这需要操作系统作大量的监控工作以防止文件重写，并保证用户能够看到最新信息。这种方法即使实现得很好，许多环境中的处理要求和网络通信量也可能使它变得不可接受。

分布式系统的优点

分布式系统与集中式系统相比较而言的优点

系统倾向于分布式发展潮流的真正驱动力是经济。25年前，计算机权威和评论家Herb Grosch指出CPU的计算能力与它的价格的平方成正比，后来成为Grosch定理。也就是说如果你付出两倍的价钱，就能获得四倍的性能。这一论断与当时的大型机技术非常吻合，因而使得许多机构都尽其所能购买最大的单个大型机。

随着微处理机技术的发展，Grosch定理不再适用了。到了二十一世纪初期，人们只需花几百美元就能买到一个CPU芯片，这个芯片每秒钟执行的指令比80年代最大的大型机的处理机每秒钟所执行的指令还多。如果你愿意付出两倍的价钱，将得到同样的CPU，但它却以更高的时钟速率运行。因此，最节约成本的办法通常是在一个系统中使用集中在一起的大量的廉价CPU。所以，倾向于分布式系统的主要原因是它可以潜在地得到比单个的大型集中式系统好得多的性价比。实际上，分布式系统是通过较低廉的价格来实现相似的性能的。

与这一观点稍有不同的是，我们发现微处理机的集合不仅能产生比单个大型主机更好的性能价格比，而且还能产生单个大型主机无论如何都不能达到的绝对性能。例如，按二十一世初期的技术，我们能够用10,000个现代CPU芯片组成一个系统，每个CPU芯片以50 MIPS（每秒百万指令）的速率运行，那么整个系统的性能就是500,000 MIPS。而如果单个处理机（即CPU）要达到这一性能，就必需在2×10-12 秒（2 微微秒，0.002纳秒）的时间内执行一条指令，然而没有一个现存的计算机能接近这个速度，从理论上和工程上考虑都认为能达到这一要求的计算机都是不可能存在的。理论上，爱因斯坦的相对论指出光的传播速度最快，它能在2 微微秒内传播0.6毫米。实际上，一个包含于边长为0.6 毫米大小的立方体内的具有上面所说的计算速度的计算机产生大量的热量就能将它自己立即熔掉。所以，无论是要以低价格获得普通的性能还是要以较高的价格获得极高的性能，分布式系统都能够满足。

另一方面，一些作者对分布式系统和并行系统进行了区分。他们认为分布式系统是设计用来允许众多用户一起工作的，而并行系统的唯一目标就是以最快的速度完成一个任务，就像我们的速度为500,000 MIPS的计算机那样。我们认为，上述的区别是难以成立的，因为实际上这两个设计领域是统一的。我们更愿意在最广泛的意义上使用“分布式系统”一词来表示任何一个有多个互连的CPU协同工作的系统。

建立分布式系统的另一原因在于一些应用本身是分布式的。一个超级市场连锁店可能有许多分店，每个商店都需要采购当地生产的商品（可能来自本地的农场）、进行本地销售，或者要对本地的哪些蔬菜因时间太长或已经腐烂而必须扔掉作出决定。因此，每个商店的本地计算机能明了存货清单是有意义的，而不是集中于公司总部。毕竟，大多数查询和更新都是在本地进行的。然而，连锁超级市场的高层管理者也会不时地想要了解他们还有多少甘蓝。实现这一目标的一种途径就是将整个系统建设成对于应用程序来说就像一台计算机一样，但是在实现上它是分布的，像我们前面所描述的一个商店有一台机器。这就是一个商业分布式系统。

另一种固有的分布式系统是通常被称为计算机支持下的协同工作系统（CSCW，Computer Supported Cooperative Work）。在这个系统中，一组相互之间在物理上距离较远的人员可以一起进行工作，例如，写出同一份报告。就计算机工业的长期发展趋势来说，人们可以很容易的想像出一个全新领域--计算机支持的协同游戏（CSCG：Computer Supported Cooperative Games）。在这个游戏中，不在同一地方的游戏者可以实时的玩游戏。你可以想像，在一个多维迷宫中玩电子捉迷藏，甚至是一起玩一场电子空战，每个人操纵自己的本地飞行模拟器去试着击落别的游戏者，每个游戏者的屏幕上都显示出其飞机外的情况，包括其它飞入它的视野的飞机。

同集中式系统相比较，分布式系统的另一个潜在的优势在于它的高可靠性。通过把工作负载分散到众多的机器上，单个芯片故障最多只会使一台机器停机，而其它机器不会受任何影响。理想条件下，某一时刻如果有5%的计算机出现故障，系统将仍能继续工作，只不过损失5%的性能。对于关键性的应用，如核反应堆或飞机的控制系统，采用分布式系统来实现主要是考虑到它可以获得高可靠性。

最后，渐增式的增长方式也是分布式系统优于集中式系统的一个潜在的重要的原因。通常，一个公司会买一台大型主机来完成所有的工作。而当公司繁荣扩充、工作量就会增大，当其增大到某一程度时，这个主机就不能再胜任了。仅有的解决办法是要么用更大型的机器（如果有的话）代替现有的大型主机，要么再增加一台大型主机。这两种作法都会引起公司运转混乱。相比较之下，如果采用分布式系统，仅给系统增加一些处理机就可能解决这个问题，而且这也允许系统在需求增长的时候逐渐进行扩充。表1-1中总结了以上这些优点。

项目	描述
经济	微处理机提供了比大型主机更好的性能价格比
速度	分布式系统总的计算能力比单个大型主机更强
固有的分布性	一些应用涉及到空间上分散的机器
可靠性	如果一个机器崩溃,整个系统还可以运转
渐增	计算能力可以逐渐有所增加

从长远的角度来看，主要的驱动力将是大量个人计算机的存在和人们共同工作与信息共享的需要，这种信息共享必需是以一种方便的形式进行的，而不受地理或人员、数据，机器的物理分布的影响。

分布式系统与独立PC机相比较的优点

既然使用微处理机是一种节省开支的办法，那么为什么不给每个人一台个人计算机，让他们各自独立地工作呢？一则，许多用户需要共享数据。例如，机票预订处的工作人员需要访问存储航班以及现有座位信息的主数据库。假如给每个工作人员都备份整个数据库，那么在实际中这是无法工作的，因为没有人知道其他工作人员已经卖出了哪些座位。共享的数据是上例和许多其它应用的基础，所以计算机间必须互连。而计算机互连就产生了分布式系统。

共享并不只是仅仅涉及数据。昂贵的外设，例如彩色激光打印机，照相排版机以及大型存储设备（如自动光盘点唱机）都是共享资源。

把一组孤立的计算机连成一个分布式系统的第三个原因是它可以增强人与人之间的沟通，电子邮件比信件、电话和传真有更多的诱人之处。它比信件快的多，不像电话需要两人同时都在，也不像传真，它所产生的文件可在计算机中进行编辑、重排和存储，也可以由文本处理程序来处理。

最后，分布式系统可能比给每个用户一个独立的计算机更灵活。尽管一种可能的模式是给每个人一台个人计算机并把它们通过LAN联在一起，但这种方式并不是唯一的。另外还存在一种模式是将个人计算机和共享计算机混合连接在一起（这些机器的型号可能并不完全相同），使工作能够在最合适的计算机上完成，而并不总是在自己的计算机上完成。这种方式可以使工作负荷能更有效地在计算机系统中进行分配。系统中某些计算机的失效也可以通过使其工作在其它计算机上进行而得到补偿。表1-2总结了以上所介绍的各点。

项目	描述
数据共享	允许多个用户访问一个公共的数据库
设备共享	允许多个用户共享昂贵的外围设备(如彩色打印机)
通信	使得人们之间的通信更加容易,如通过电子邮件
灵活性	用最有效的方式将工作负荷分配到可用的机器上

主流开源分布式系统架构都有哪些？

分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。分布式文件系统的设计基于客户机/服务器模式。一个典型的网络可能包括多个供多用户访问的服务器。另外，对等特性允许一些系统扮演客户机和服务器的双重角色。例如，用户可以“发表”一个允许其他客户机访问的目录，一旦被访问，这个目录对客户机来说就像使用本地驱动器一样，下面是三个基本的分布式文件系统。

中文名：分布式文件系统 外文名：Distributed File System

基于：客户机/服务器模式 分类：NFS AFS KASS DFS

项链方式：通过计算机网络与节点相连（这样就决定网络架构必须要采用内网或者专线，不然分布式文件存储毫无意义）

相关名词：分布式文件存储和分布式计算

一些常见的分布式系统大类：

a）支持持久化存储的分布式存储系统；

b）着重计算的分布式计算框架；

c）分布式消息队列

根据不同的应用的领域，把上述分类细化，常见分布式存储系统分为：

分布式协同系统（分布式日志复制）
分布式任务调度框架
流计算框架
分布式文件/对象系统
分布式NoSQL存储
分布式关系数据库（OLAP、OLTP）；
各种消息队列mq

分布式协调系统（日志复制系统）其实就是paxos算法及其变体的实现，典型的有zookeeper、etcd；一般来说只存少量的元数据信息，重点在高可用强一直，是很多分布式系统不可或缺的组件；
开源的分布式文件/对象系统比较有名的包括Lustre（HPC）GlusterFS（NAS NFS）、HDFS（hadoop）、ceph（虚机块存储）、swift（restful对象存储），各有不同的领域。
NoSQL分布式存储种类和数量最多，按照Martin Fowler大师的分类，包括Aggregated Oriented NoSQL和图数据库NoSql；Aggregated Oriented NoSQL大致分为3类：

1.Key-value NoSQL，例如Redis Riak等；

2.column family NoSQL(wide column store)，典型的是Hbase Cassandra；

3.document NoSQL,典型的是mongodb

有几个大的维度来区分：有状态、无状态；着重存储还是着重计算；long service还是批处理。

功能分: olap, oltp, 分布式日志，share-nothing, numa, MapReduce, DAG.
数据分:表格，对象，文件，关系。
架构分: 类bigtable, 类dynamo
日志复制分: primary-backup，gossip，quorum.同步，半同步，异步。
数据切分分:hash,range
workload分:很多种
membership分:自己选主，主控节点选主，dlm选主。
CAP折衷分:强一致性牺牲可用性，最终一致性更高的可用性。

既然是关于分布式文件系统的，就多说几句

1.GlusterFS 文件系统标准的posix接口支持，可以做分布式NAS，也有人HPC，甚至支持KVM的虚机卷；做分布式NAS最多，其他方面用的不多，很多互联网视频公司用GlusterFS来做片库；

2.ceph，支持块ceph RBD，对象ceph RGW，文件cephfs；ceph RBD和ceph RGW比较成熟，在openstack社区比较火，做虚机块存储用的很多，cephfs的前期bug比较多，社区目前也在解决这些问题；

3.Lustre，比较老牌的分布式文件系统，部署在多个san阵列上，不支持副本，支持分布式锁，主要做HPC高性能计算；

4.HDFS只支持追加写，设计中没有考虑修改写、截断写、稀疏写等复杂的posix语义，目的并不是通用的文件系统，一般作为hadoop ecosystem的存储引擎；

5.moosefs 比较接近GoogleFS的c++实现，通过fuse支持了标准的posix，算是通用的文件系统，可惜社区不是太活跃；

6.IBM的GPFS也是一个很老牌的分布式文件系统，非常强大，有两个分支，一个是通用文件系统，一个是兼容hadoop mapreduce，可惜没有开源，国内也没人买的起；

7.facebook Haystack是一个专有的图片存储系统的原型，适合小文件和worm场景（write once read many），本身并没有开源，github上已经有一个比较成熟的实现Terry-Mao/bfs（不是百度的BFS）

这里有一个混淆的概念，分布式文件系统vs分布式计算。
我看题目的描述，你需要分布式计算（音视频处理放在云端），所以你后来提到的GlusterFS等等不能解决你的问题。它们只是分布式文件系统。

分布式计算至少要求任务是可分解的，音视频要看你具体的文件格式，没有通用的解决方案。
传统的处理音频视频大文件的方法是SAN，用一台很贵的机器，接一个很贵的网，连上很贵的存储。

主要看你的具体业务和存储+访问场景，其实现在音视频比如制播之类用得多的还是类似于SAN之类的东西。

FastDFS 针对大量小文件存储有优势，这种场景嗯...没有用过。
hadoop的hdfs适合大文件存储，顺序读取类型的应用，你看看你们的应用场景是否适合，btw,hdfs随机访问延时挺大的. 顺序访问也要优化好才吞吐高啊。

Atitit 分布式文件系统总结 fastdfs nfs smb webdav ftp

webdav 是个好的方案。。。Server client都有

ftp也方便java lib实现server client。。。

Smb 服务端麻烦。。没有好的java lib server实现。。。

nfs 也是没有好的 java libserver实现

fastdfs 没有lib实现模式，只能源码安装

FastDFS特性及问题思考

FastDFS是国人开发的一款分布式文件系统，目前社区比较活跃。系统中存在三种节点：Client、Tracker、Storage，在底层存储上通过逻辑的分组概念，使得通过在同组内配置多个Storage，从而实现软RAID10，提升简单负载均衡、并发IO的性能、及数据的冗余备份；同时通过线性的添加新的逻辑存储组，从容实现存储容量的线性扩容。

文件下载上，除了支持通过API方式，目前还提供了apache和nginx的插件支持，同时也可以不使用对应的插件，直接以Web静态资源方式对外提供下载。目前FastDFS(V4.x)代码量大概6w多行，内部的网络模型使用比较成熟的libevent三方库，具备高并发的处理能力

优点

1）系统无需支持POSIX(可移植操作系统)，降低了系统的复杂度，处理效率更高
2）支持在线扩容机制，增强系统的可扩展性
3）实现了软RAID，增强系统的并发处理能力及数据容错恢复能力
4）支持主从文件，支持自定义扩展名
5）主备Tracker服务，增强系统的可用性

缺点

1）不支持断点续传，对大文件将是噩梦(FastDFS不适合大文件存储)
2）不支持POSIX通用接口访问，通用性较低
3）对跨公网的文件同步，存在较大延迟，需要应用做相应的容错策略
4）同步机制不支持文件正确性校验，降低了系统的可用性
5）通过API下载，存在单点的性能瓶颈

NFS和AFS的区别

其实微软的操作系统还有DFS分布式文件管理系统吗，不过使用的场景较少，此文不在讲述，感兴趣者可以自行百度。

NFS和AFS的区别在于对并发写操作的处理方法上。当一个客户机向服务器请求一个文件(或数据库记录)，文件被放在客户工作站的高速缓存中，若另一个用户也请求同一文件，则它也会被放入那个客户工作站的高速缓存中。当两个客户都对文件进行修改时，从技术上而言就存在着该文件的三个版本(每个客户机一个，再加上服务器上的一个)。有两种方法可以在这些版本之间保持同步：

无状态系统在这个系统中，服务器并不保存其客户机正在缓存的文件的信息。因此，客户机必须协同服务器定期检查是否有其他客户改变了自己正在缓存的文件。这种方法在大的环境中会产生额外的LAN通信开销，但对小型LAN来说，这是一种令人满意的方法。NFS就是个无状态系统。

回呼(Callback)系统在这种方法中，服务器记录它的那些客户机的所作所为，并保留它们正在缓存的文件信息。服务器在一个客户机改变了一个文件时使用一种叫回叫应答(callbackpromise)的技术通知其它客户机。这种方法减少了大量网络通信。AFS(及OSFDCE的DFS)就是回叫系统。客户机改变文件时，持有这些文件拷贝的其它客户机就被回叫并通知这些改变。

无状态操作在运行性能上有其长处，但AFS通过保证不会被回叫应答充斥也达到了这一点。方法是在一定时间后取消回叫。客户机检查回叫应答中的时间期限以保证回叫应答是当前有效的。回叫应答的另一个有趣的特征是向用户保证了文件的当前有效性。换句话说，若一个被缓存的文件有一个回叫应答，则客户机就认为文件是当前有效的，除非服务器呼叫指出服务器上的该文件已改变了。

各种分布式文件系统的比较

适合做通用文件系统的有 MooseFS，GlusterFS，Lustre。

适合存储小文件、图片的分布文件系统有FastDFS、NFS和TFS。（传统的方式是Rsync+inotify或者其他同步软件）

MooseFS

支持FUSE，相对比较轻量级，对master服务器有单点依赖，用perl编写，性能相对较差，国内用的人比较多，易用，稳定，对小文件很高效。


+ 支持文件元信息
+ mfsmount 很好用
+ 编译依赖少，文档全，默认配置很好
+ mfshdd.cfg 加 * 的条目会被转移到其它 chunk server，以便此 chunk server 安全退出
+ 不要求 chunk server 使用的文件系统格式以及容量一致
+ 开发很活跃
+ 可以以非 root 用户身份运行
+ 可以在线扩容
+ 支持回收站
+ 支持快照
- master server 存在单点故障
- master server 很耗内存

MogileFS

Key-Value型元文件系统，不支持FUSE，应用程序访问它时需要API，主要用在web领域处理海量小图片，效率相比mooseFS高很多，据说对于 Web 2.0 应用存储图片啥的很好。

不适合做通用文件系统，适合存储静态只读小文件，比如图片

GlusterFS

支持FUSE，比mooseFS庞大，感觉广告宣传做的比产品本身好。


+ 无单点故障问题
+ 支持回收站
+ 模块化堆叠式架构
- 对文件系统格式有要求，ext3/ext4/zfs 被正式支持，xfs/jfs 可能可以，reiserfs 经测试可以
- 需要以 root 用户身份运行（用了 trusted xattr，mount 时加 user_xattr 选项是没用的，官方说法是glusterfsd 需要创建不同属主的文件，所以必需 root 权限)
- 不能在线扩容(不 umount 时增加存储节点)，计划在 3.1 里实现
- 分布存储以文件为单位，条带化分布存储不成熟

GFS2

http://sourceware.org/cluster/wiki/DRBD_Cookbook
http://www.smop.co.uk/blog/index.php/2008/02/11/gfs-goodgrief-wheres-the-documentation-file-system/
http://wiki.debian.org/kristian_jerpetjoen
http://longvnit.com/blog/?p=941
http://blog.chinaunix.net/u1/53728/showart_1073271.html (基于红帽RHEL5U2 GFS2+ISCSI+XEN+Cluster 的高可性解决方案)
http://www.yubo.org/blog/?p=27 (iscsi+clvm+gfs2+xen+Cluster)
http://linux.chinaunix.net/bbs/thread-777867-1-1.html

并不是 distributed file system, 而是 shared disk cluster file system，需要某种机制在机器
之间共享磁盘，以及加锁机制，因此需要 drbd/iscsi/clvm/ddraid/gnbd 做磁盘共享，以及 dlm 做锁管理)
- 依赖 Red Hat Cluster Suite (Debian: aptitude install redhat-cluster-suite，图形配置工具包
system-config-cluster, system-config-lvm)
- 适合不超过约 30 个节点左右的小型集群，规模越大，dlm 的开销越大，默认配置 8 个节点

OCFS2

GFS 的 Oracle 翻版，据说性能比 GFS2 好 (Debian: aptitude install ocfs2-tools, 图形配置工具包 ocfs2console)
不支持 ACL、flock，只是为了 Oracle database 设计

OpenAFS/Coda

是很有特色的东西。


+ 成熟稳定
+ 开发活跃，支持 Unix/Linux/MacOS X/Windows
- 性能不够好

Ceph

支持FUSE，客户端已经进入了linux-2.6.34内核，也就是说可以像ext3/rasierFS一样，选择ceph为文件系统。彻底的分布式，没有单点依赖，用C编写，性能较好。基于不成熟的btrfs，其本身也非常不成熟。

是加州大学圣克鲁兹分校的Sage weil攻读博士时开发的分布式文件系统。并使用Ceph完成了他的论文。
说 ceph 性能最高，C++编写的代码，支持Fuse，并且没有单点故障依赖，于是下载安装，由于 ceph 使用 btrfs 文件系统，而btrfs 文件系统需要 Linux 2.6.34 以上的内核才支持。
可是ceph太不成熟了，它基于的btrfs本身就不成熟，它的官方网站上也明确指出不要把ceph用在生产环境中。【可是现在聚集了大量国内社区的热衷，并且得到很多云计算公司的青睐，此项技术已经越来越受用和成熟。时代变啦】
　　

Lustre

Oracle公司的企业级产品，非常庞大，对内核和ext3深度依赖
复杂，高效，适合大型集群。


* 适合大型集群
+ 很高性能
+ 支持动态扩展
- 需要对内核打补丁，深度依赖 Linux 内核和 ext3 文件系统

PVFS2

搭配定制应用会很好，据说曙光的并行文件系统就是基于 PVFS。　　fastDFS：国人在mogileFS的基础上进行改进的key-value型文件系统，同样不支持FUSE，提供比mogileFS更好的性能。


* 高性能
- 没有锁机制，不符合 POSIX 语意，需要应用的配合，不适合做通用文件系统
(See pvfs2-guide chaper 5:
PVFS2 User APIs and Semantics)
- 静态配置，不能动态扩展

Coda


* 从服务器复制文件到本地，文件读写是本地操作因此很高效
* 文件关闭后发送到服务器
+ 支持离线操作，连线后再同步到服务器上
- 缓存基于文件，不是基于数据块，打开文件时需要等待从服务器缓存到本地完毕
- 并发写有版本冲突问题
- 并发读有极大的延迟，需要等某个 client 关闭文件，比如不适合 tail -f some.log
- 研究项目，不够成熟，使用不广

Hadoop HDFS

本地写缓存，够一定大小 (64 MB) 时传给服务器
不适合通用文件系统

Hadoop 实现了一个分布式文件系统（Hadoop Distributed File System），简称HDFS。 Hadoop是Apache Lucene创始人Doug Cutting开发的使用广泛的文本搜索库。它起源于Apache Nutch，后者是一个开源的网络搜索引擎，本身也是Luene项目的一部分。Aapche Hadoop架构是MapReduce算法的一种开源应用，是Google开创其帝国的重要基石。

FastDFS

是一款类似Google FS的开源分布式文件系统，是纯C语言开发的。
FastDFS是一个开源的轻量级分布式文件系统，它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等等。

- 只能通过 API 使用，不支持 fuse

NFS

　　老牌网络文件系统，具体不了解，反正NFS最近几年没发展，肯定不能用。
　　

dCache

依赖 PostgreSQL

xtreemfs

* 服务端是 Java 实现的
- 性能不高

CloudStore (KosmosFS)

+ 被 Hadoop 作为分布式文件系统后端之一
- 不支持文件元信息
- kfs_fuse 太慢，不可用
- 编译依赖多，文档落后，脚本简陋
- 开发不活跃

NFSv4 Referrals

+ 简单
- 没有负载均衡，容错

NFSv4.1 pNFS

- 没有普及

spNFS

* pNFS 在 Linux 上的一个实现

Ceph (http://ceph.newdream.net/)
- 开发初期，不稳定
- 依赖 btrfs

GFarm

http://datafarm.apgrid.org/software/

MogileFS

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
由memcahed的开发公司danga一款perl开发的产品，目前国内使用mogielFS的有图片托管网站yupoo等。
MogileFS是一套高效的文件自动备份组件，由Six Apart开发，广泛应用在包括LiveJournal等web2.0站点上。
MogileFS由3个部分组成：
　　第1个部分是server端，包括mogilefsd和mogstored两个程序。前者即是 mogilefsd的tracker，它将一些全局信息保存在数据库里，例如站点domain,class,host等。后者即是存储节点(store node)，它其实是个HTTP Daemon，默认侦听在7500端口，接受客户端的文件备份请求。在安装完后，要运行mogadm工具将所有的store node注册到mogilefsd的数据库里，mogilefsd会对这些节点进行管理和监控。
　　第2个部分是utils（工具集），主要是MogileFS的一些管理工具，例如mogadm等。
　　第3个部分是客户端API，目前只有Perl API(MogileFS.pm)、PHP，用这个模块可以编写客户端程序，实现文件的备份管理功能。

TFS

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
TFS（Taobao !FileSystem）是一个高可扩展、高可用、高性能、面向互联网服务的分布式文件系统，主要针对海量的非结构化数据，它构筑在普通的Linux机器集群上，可为外部提供高可靠和高并发的存储访问。TFS为淘宝提供海量小文件存储，通常文件大小不超过1M，满足了淘宝对小文件存储的需求，被广泛地应用在淘宝各项应用中。它采用了HA架构和平滑扩容，保证了整个文件系统的可用性和扩展性。同时扁平化的数据组织结构，可将文件名映射到文件的物理地址，简化了文件的访问流程，一定程度上为TFS提供了良好的读写性能。
官网： http://code.taobao.org/p/tfs/wiki/index/

但是，现在开源虽好，但面对日益增长的用户需求和复杂的架构变更，以上分布式文件存储系统已经不能满足企业实际发展需要例如断电或者网络抖动都会对存储产生影响，很多公司都基于二次开发或者独立研发自己的分布式文件存储系统，例如七牛和青云等云厂商公司。对于技术缺乏的公司建议使用商业的分布式存储，这样可以减少很多麻烦。