Comparative __ubuntu/centos Management of various Distributed file systems

It is suitable to do common file system with Moosefs,glusterfs,lustre. Moosefs

Support Fuse, relatively lightweight, the master server has a single point of dependence, written in Perl, relatively poor performance, domestic use more people, easy-to-use, stable, very efficient for small files.

    + Support file meta information
    + Mfsmount is very easy to use
    + compile-dependent, document complete, the default configuration is very good
    + mfshdd.cfg Add * entries will be transferred to other chunk server, so that this chunk server safe exit 
  
   + does not require chunk server to use File system format and capacity consistent
    + development is very active
    + can run as a non-root user
    + can be online expansion
    + support Recycle Bin
    + support snapshots
    -Master Server has a single point of failure
    -the master server consumes memory
  

MogileFS

Key-value-Type metafile system, does not support fuse, the application access it requires APIs, mainly used in the web to deal with a large number of small pictures, the efficiency of a lot more than moosefs, is said to the Web 2.0 applications to store pictures what is very good.

Not suitable for common file system, suitable for storing static read-only small files, such as Picture Glusterfs

Support Fuse, larger than the moosefs, feel advertising to do better than the product itself.

    + No single point of failure problem
    + support Recycle Bin
    + Modular Tiered architecture
    -required for file system format, EXT3/EXT4/ZFS is officially supported, XFS/JFS may be available, ReiserFS tested

    -requires root User identity run (trusted xattr,mount with the user_xattr option is useless, the official saying is that GLUSTERFSD need to create a different owner of the file, so must root permissions)
    -Can not be expanded online (not umount add storage section Point), planned to be implemented in 3.1
    -distributed storage in file units, striped distribution storage immature

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 (based on Red Hat rhel5u2 gfs2+iscsi+ Xen+cluster solution for High scalability)
http://www.yubo.org/blog/?p=27 (iscsi+clvm+gfs2+xen+cluster)
http:// Linux.chinaunix.net/bbs/thread-777867-1-1.html

Not distributed file system, but shared disk cluster file system, which requires some kind of mechanism in the machine
Shared disk, plus lock mechanism, so need to DRBD/ISCSI/CLVM/DDRAID/GNBD do disk sharing, and DLM do lock management)
-dependent on Red Hat Cluster Suite (debian:aptitude install redhat-cluster-suite, Graphics Configuration Toolkit
System-config-cluster, SYSTEM-CONFIG-LVM)
-Suitable for small clusters of around 30 nodes, the larger the DLM overhead, the default configuration of 8 nodes OCFS2

GFS Oracle Replica, which is said to perform better than GFS2 (debian:aptitude install Ocfs2-tools, Graphics Configuration toolkit ocfs2console)
ACL, Flock is not supported, just for Oracle database design Openafs/coda

It's a very distinctive thing.

     + Mature Stable
    + development Active, support Unix/linux/macos x/windows
    -not good performance

Ceph

Support Fuse, the client has entered the linux-2.6.34 kernel, that is to say, like Ext3/rasierfs, choose Ceph as File system. Completely distributed, no single point of Reliance, written in C, good performance. Based on immature btrfs, it is very immature in itself.
　　 Lustre

Oracle Company's enterprise-class products, very large, deep reliance on kernel and ext3
Complex, efficient, suitable for large clusters.

    * Suitable for large clusters
    + high performance
    + support dynamic expansion
    -need to patch the kernel, deep reliance on the Linux kernel and ext3 file system

PVFS2

Http://blog.csdn.net/yfw418/archive/2007/07/06/1680930.aspx
Matching custom applications would be good, and the dawning parallel file system is said to be based on PVFS. Fastdfs: The Key-value file system, which is improved on the basis of mogilefs, also does not support fuse and provides better performance than mogilefs.

    * High Performance
    -no locking mechanism, does not conform to POSIX semantics, need to apply the coordination, not suitable for common file system
      (pvfs2-guide chaper 5:  PVFS2 User APIs and Semantics)
    - Static configuration, cannot dynamically expand

Coda

    * Copy files from server to local, file read and write is local operation so very efficient
    * file is closed and sent to the server
    + support offline operation, wired and then synchronized to the server
    -cache file-based, not based on data block, When opening a file, you need to wait from the server cache to the local end
    -Concurrent Write version conflict problem
    -concurrent read has a great delay, need to wait for a client to close the file, such as not suitable for tail-f some.log
    -research projects, immature, not widely used

Hadoop HDFS

Local write cache, enough size (MB) to pass to the server
Not suitable for common file system Fastdfs

-can only be used through the API, does not support fuse

NFS

Old network File system, specifically do not understand, anyway, NFS in recent years did not develop, certainly cannot use.
　　 Dcache

Reliance on PostgreSQL

Xtreemfs

* Server side is Java implementation
-performance is not high

Cloudstore (KOSMOSFS)

+ Hadoop as one of the back-end of the Distributed file system
-does not support file meta information
-kfs_fuse is too slow, not available
-compile-dependent, document backward, script
-less-develop inactive

NFSV4 Referrals

+ Simple
-no load balancing, fault tolerant

NFSv4.1 PNFS

-No popularity

Spnfs

* An implementation of PNFS on Linux

Ceph (http://ceph.newdream.net/)
-Early development, unstable
-reliance on Btrfs Gfarm

Http://datafarm.apgrid.org/software/