1、MooseFS
支持FUSE，相對比較輕量級，對master服務器有單點依賴，用perl編寫，性能相對較差，國內用的人比較多，易用，穩定，對小文件很高效。
+ 支持文件元信息
+ mfsmount 很好用
+ 編譯依賴少，文檔全，默認配置很好
+ mfshdd.cfg 加 * 的條目會被轉移到其它 chunk server，以便此 chunk server 安全退出
+ 不要求 chunk server 使用的文件系統格式以及容量一致
+ 開發很活躍
+ 可以以非 root 用戶身份運行
+ 可以在線擴容
+ 支持回收站
+ 支持快照
- master server 存在單點故障
- master server 很耗內存
測試性能還不錯。吞吐量在15MB/秒以上
2、MogileFS
Key-Value型元文件系統，不支持FUSE，應用程序訪問它時需要API，主要用在web領域處理海量小圖片，效率相比mooseFS高很多，據說對於 Web 2.0 應用存儲圖片啥的很好。
不適合做通用文件系統，適合存儲靜態只讀小文件，比如圖片
網上說這個是性能最高的， 不過是perl編寫的代碼， 對外提供API來進行使用， 搭建相對比較復雜一點， 因為需要安裝很多依賴的第三方perl包，另外還要安裝MySQL數據庫來支持。
安裝完畢后， 服務器端起來了， 客戶端有Java， PHP, PERL, RUBY 等開發的， 我需要的是要支持 FUSE 的， 但是這個分布式的文件系統，對FUSE的支持需要安裝一個PERL與C通信的模塊， 這個模塊死活編譯不過去， 最后無法測試成功，無奈只能有時間了繼續研究。
3、GlusterFS
支持FUSE，比mooseFS龐大，感覺廣告宣傳做的比產品本身好。
+ 無單點故障問題
+ 支持回收站
+ 模塊化堆疊式架構
- 對文件系統格式有要求，ext3/ext4/zfs 被正式支持，xfs/jfs 可能可以，reiserfs 經測試可以
- 需要以 root 用戶身份運行（用了 trusted xattr，mount 時加 user_xattr 選項是沒用的，官方說法是glusterfsd 需要創建不同屬主的文件，所以必需 root 權限)
- 不能在線擴容(不 umount 時增加存儲節點)，計划在 3.1 里實現
- 分布存儲以文件為單位，條帶化分布存儲不成熟
網上說glusterfs比較不錯， 穩定，適合大型應用， 關鍵是沒有單點故障依賴，C語言的代碼， 支持FUSE，於是下載安裝研究。 安裝配置還算簡單，啟動后進行測試。
開始感覺確實不錯，很爽。 后來用壓力測試工具對其吞吐量進行測試 ， 發現性能不能滿足我們的生產需求，不知道是哪里的配置問題，
我們測試的都是大文件的讀操作和大文件的寫操作， 吞吐量在 5MB/秒左右， 顯然不能滿足要求。但是沒有找到具體的瓶頸，畢竟程序是別人寫的，要查瓶頸也不容易。
關於 glusterfs的詳細的資料， 可以看這位弟兄的文章， 他做的比較深入 。
http://zhoubo.sinaapp.com/?cat=22
4、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 個節點
5、OCFS2
GFS 的 Oracle 翻版，據說性能比 GFS2 好 (Debian: aptitude install ocfs2-tools, 圖形配置工具包 ocfs2console)
不支持 ACL、flock，只是為了 Oracle database 設計
6、OpenAFS/Coda
是很有特色的東西。
+ 成熟穩定
+ 開發活躍，支持 Unix/Linux/MacOS X/Windows
- 性能不夠好
7、ceph
支持FUSE，客戶端已經進入了Linux-2.6.34內核，也就是說可以像ext3/rasierFS一樣，選擇ceph為文件系統。徹底的分布式，沒有單點依賴，用C編寫，性能較好。基於不成熟的btrfs，其本身也非常不成熟
網上搜索了一些資料， 說 ceph 性能最高，C++編寫的代碼，支持Fuse，並且沒有單點故障依賴， 於是下載安裝， 由於 ceph 使用 btrfs 文件系統， 而btrfs 文件系統需要 Linux 2.6.34 以上的內核才支持， 顯然我使用的 RHEL5 的內核還不支持 btrfs文件系統， 於是下載最新的內核進行升級， 搞了2天沒有升級成功， 編譯一次都要耗費1個多小時才能完成，最后發現最新版的 ubuntu 系統支持btrfs文件系統， 於是安裝 ubuntu 的虛擬機，btrfs 文件系統搞定了， 但是啟動ceph的相關進程出錯， 無法啟動成功。所以談不上對其進行過測試。
CEPH中使用了一個比較先進的算法 crush算法， 據翻譯出來，為分布式基於對象的存儲系統設計了一個可升級的偽隨機的數據分布函數，它能夠有效地管理數據對象和存儲設備，而不需要通過一個中心目錄。由於大系統都是動態的，CRUSH被設計成為一個當把不需要的數據遷移最小化時，能方便的增加或移除存儲設備。這個算法提供了一個大范圍的不同種類的數據復制和可靠性機制，以及根據用戶自定義的策略來分配數據，這種策略迫使數據復制從故障領域分離出來。
另外CEPH使用的文件系統為btrfs， 這個文件系統具有很多先進的特性， 為下一代Linux使用的文件系統。
BTRFS最終可能會給ZFS等帶來更多威脅，它具有在線碎片整理功能(只有固態盤有這項功能)、Copy-On-Write技術、數據壓縮、鏡像、數據條帶和快照等等。
另外，BTRFS在數據存儲方面比ext更完善。它包括一些邏輯卷管理和RAID硬件功能，可以對內部元數據和用戶數據進行檢驗和，同時內嵌了快照功能。ext4也可以實現以上一些功能，但是需要與文件系統和邏輯卷管理器進行通信。
8、Lustre
Oracle公司的企業級產品，非常龐大，對內核和ext3深度依賴
復雜，高效，適合大型集群。
* 適合大型集群
+ 很高性能
+ 支持動態擴展
- 需要對內核打補丁，深度依賴 Linux 內核和 ext3 文件系統
這個東西連下載地址都沒有了。。。。。
9、PVFS2
http://blog.csdn.net/yfw418/archive/2007/07/06/1680930.aspx
搭配定制應用會很好，據說曙光的並行文件系統就是基於 PVFS。
10、fastDFS：國人在mogileFS的基礎上進行改進的key-value型文件系統，同樣不支持FUSE，提供比mogileFS更好的性能。
* 高性能
- 沒有鎖機制，不符合 POSIX 語意，需要應用的配合，不適合做通用文件系統
(See pvfs2-guide chaper 5: PVFS2 User APIs and Semantics)
- 靜態配置，不能動態擴展
網上說是“國人在mogileFS的基礎上進行改進的key-value型文件系統，同樣不支持FUSE，提供比mogileFS更好的性能”， 這不是扯蛋嗎 ？ Mogilefs 是perl寫的， 如果 fastDFS是在 mogilefs 的基礎上改進的話， 應該也是perl寫的， 但是下載了fastDFS的代碼后， 人家都是C的代碼， 怎么可能是在mogilefs的基礎上改進呢 ？看了一下fastDFS具體的結構，准確的說應該是“借鑒了MogileFS的思路”，而不能說“在MogileFS的基礎上改進”。
我安裝了一下， 安裝還算簡單， 不支持fuse， 上傳文件后會生成一個http的下載地址， 通過http的方式進行下載。這種方式顯然不適合我想要的生產環境。
下面是一個網友寫的 FastFDS和MogileFS的對比文章， 感覺比較客觀真實， 所以在這里給大家轉帖一下。
FastDFS設計時借鑒了MogileFS的一些思路。FastDFS是一個完善的分布式文件存儲系統，通過客戶端API對文件進行讀寫。可以說，MogileFS的所有功能特性FastDFS都具備，MogileFS網址：http://www.danga.com/mogilefs/。
另外，相對於MogileFS，FastDFS具有如下特點和優勢：
a. FastDFS完善程度較高，不需要二次開發即可直接使用；
b. 和MogileFS相比，FastDFS裁減了跟蹤用的數據庫，只有兩個角色：tracker和storage。FastDFS的架構既簡化了系統，同時也消除了性能瓶頸；
c. 在系統中增加任何角色的服務器都很容易：增加tracker服務器時，只需要修改storage和client的配置文件（增加一行tracker配置）；增加storage服務器時，通常不需要修改任何配置文件，系統會自動將該卷中已有文件復制到該服務器；
d. FastDFS比MogileFS更高效。表現在如下幾個方面：
1）參見上面的第2點，FastDFS和MogileFS相比，沒有文件索引數據庫，FastDFS整體性能更高；
2）從采用的開發語言上看，FastDFS比MogileFS更底層、更高效。FastDFS用C語言編寫，代碼量不到2萬行，沒有依賴其他開源軟件或程序包，安裝和部署特別簡潔；而MogileFS用perl編寫；
3）FastDFS直接使用socket通信方式，相對於MogileFS的HTTP方式，效率更高。並且FastDFS使用sendfile傳輸文件，采用了內存零拷貝，系統開銷更小，文件傳輸效率更高。
e. FastDFS有着詳細的設計和使用文檔，而MogileFS的文檔相對比較缺乏。
f. FastDFS的日志記錄非常詳細，系統運行時發生的任何錯誤信息都會記錄到日志文件中，當出現問題時方便管理員定位錯誤所在。
g. FastDFS還對文件附加屬性（即meta data，如文件大小、圖片寬度、高度等）進行存取，應用不需要使用數據庫來存儲這些信息。
h. FastDFS從V1.14開始支持相同文件內容只保存一份，這樣可以節省存儲空間，提高文件訪問性能。
11、Coda
* 從服務器復制文件到本地，文件讀寫是本地操作因此很高效
* 文件關閉后發送到服務器
+ 支持離線操作，連線后再同步到服務器上
- 緩存基於文件，不是基於數據塊，打開文件時需要等待從服務器緩存到本地完畢
- 並發寫有版本沖突問題
- 並發讀有極大的延遲，需要等某個 client 關閉文件，比如不適合 tail -f some.log
- 研究項目，不夠成熟，使用不廣
12、Hadoop HDFS
本地寫緩存，夠一定大小 (64 MB) 時傳給服務器
不適合通用文件系統
13、FastDFS
- 只能通過 API 使用，不支持 fuse
14、NFS
老牌網絡文件系統，具體不了解，反正NFS最近幾年沒發展，肯定不能用。
15、dCache
依賴 PostgreSQL
16、xtreemfs
* 服務端是 Java 實現的
- 性能不高
17、CloudStore (KosmosFS)
+ 被 Hadoop 作為分布式文件系統后端之一
- 不支持文件元信息
- kfs_fuse 太慢，不可用
- 編譯依賴多，文檔落后，腳本簡陋
- 開發不活躍
18、NFSv4 Referrals
+ 簡單
- 沒有負載均衡，容錯
19、NFSv4.1 pNFS
- 沒有普及
20、spNFS
* pNFS 在 Linux 上的一個實現
Ceph (http://ceph.newdream.net/)
- 開發初期，不穩定
- 依賴 btrfs
21、GFarm
http://datafarm.apgrid.org/software/