分布式文件系统试用比较

IT民工

MooseFS 很不错，已经实用了半月了，易用，稳定，对小文件很高效。

MogileFS 据说对于 Web 2.0 应用存储图片啥的很好。

GlusterFS 感觉广告宣传做的比产品本身好。

OpenAFS/Coda 是很有特色的东西。

Lustre 复杂，高效，适合大型集群。

PVFS2 搭配定制应用会很好，据说曙光的并行文件系统就是基于 PVFS。

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

================================================================

dCache
- 依赖 PostgreSQL

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

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

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

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

GlusterFS (特性)
+ 无单点故障问题
+ 支持回收站
+ 模块化堆叠式架构
- 对文件系统格式有要求，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
+ 成熟稳定
+ 开发活跃，支持 Unix/Linux/MacOS X/Windows
- 性能不够好

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

PVFS2
http://blog.csdn.net/yfw418/archive/2007/07/06/1680930.aspx
* 高性能
- 没有锁机制，不符合 POSIX 语意，需要应用的配合，不适合做通用文件系统
(See pvfs2-guide chaper 5: PVFS2 User APIs and Semantics)
- 静态配置，不能动态扩展

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

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

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

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

NFSv4.1 pNFS
- 没有普及

spNFS
* pNFS 在 Linux 上的一个实现

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

原文：http://selboo.com.cn/post/866/

sdasd0224

政府机构
问题：
部门较多，沟通不便
异地会议，出差频繁
层级和数量较多，民众上T访不便
ppmeet网页版视频会议+即时通讯解决方案
网络会议面对面，即时沟通解决问题，精简办公流程，为百姓更多的做实事。
       
远程培训
问题：
频繁的演示文档，讲师与学员互动
ppmeet网页版视频会议+即时通讯解决方案
完善的文档演示功能，与会角色切换，相互语音交流，充分实现讲师与学员之间的互动，提升学习效果。

医疗行业
问题：
分支机构较多，学术讨论、会诊等频繁的会议需求。
部分病患需反复就诊，费时费力
ppmeet网页版视频会议+即时通讯解决方案
通过功能强大的文档演示功能，使得会议讨论，学术研究有了更为具体和直观的体现；
远程病例共享，在线病例分析，为病患治疗争取更多时间，提高患者治愈率。

IT企业
问题：
频繁的技术研讨，方案策划，
传统笔记效率低，且无法形象的描述出会议中所需要表达的想法和创意
ppmeet网页版视频会议+即时通讯解决方案
重要文档资料一键下载，会议中演示文件截屏后一同纳入会议文档，便于存档和管理，会议录制，会议场景可随时再现。

广告公司
问题：
频繁的客户预约和交流，众多的方案PPT及作品演示
ppmeet网页版视频会议+即时通讯解决方案
通过文档演示及时商议设计方案稿，坐在办公室就能与客户的轻松交流，完成方案定稿和推广方案。

实业公司
问题：
与供货商，客户之间频繁的样品展示需求，占用企业过资源
ppmeet网页版视频会议+即时通讯解决方案
通过文档演示以网页剪取，坐在办公室就能与客户的轻松交流，并实现样品展示、商务谈判。