1、为什么分布式文件系统要采用特定的组织结构来存储文件？
直接按照文件的原始路径进行存储和复制，这样就可以直接通过应用服务进行静态化访问，从而大幅度提升性能。怎么样，这个主意不错吧？
等等，我们好像又绕回去了…..
这样的一个系统，大概是一个共享文件系统?或者是一个文件分发系统。
如果只是共享文件系统，文件太多了怎么办？文件访问压力太大了怎么办？文件丢失了怎么办？文件错了怎么办？文件服务器挂了怎么办？
怎么办，怎么办，怎么办？
没有那么多怎么办，所以我们在经历过这些实践和使用之后，结论就是，用分布式文件系统，就这么办。
2、分布式文件系统能够帮我们做什么（优点）
可以组建包含大量廉价服务器的海量存储系统，这是文件分发和同步不容易做到的；
通过内部的冗余复制，保证文件的可用性，在海量存储系统中，容错能力非常非常重要；
可扩展性很强，增加存储节点和追踪器都比较容易；
在多个文件副本之间就进行负载均衡，可以通过横向扩展来确保性能的提升。
进行特定的索引文件的计算等；
…
3、分布式文件系统的不足或者说缺点
低延时访问
分布式文件系统不太适合于那些要求低延时（数十毫秒）访问的应用程序，因为分布式文件系统是设计用于海量数据处理的，这是以一定延时为代价的。对于低延时访问，经典和传统的办法就是数据库，我们所喜爱的ORACLE就很擅长干这个事情。
比如一个支付系统，对于它的核心支付体系，后端用P590小型机+ORACLE，当支付的规模越来越大的时候。小型机+ORACLE的支付体系会非常痛苦。对数据库横向扩展，水平切分都是方法，但是直接想把核心支付模块切换到分布式文件系统上，确实有挑战，当年没有成功过。（一家之言，说不定你们能搞定，仅供参考）
频繁修改的文件的应用
目前常用的分布式文件系统，基本都是“一次写多次读”的模式，如果涉及到大量数据的频繁修改，那么这个问题就相对比较麻烦；
海量小文件
分布式文件系统把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是有限的。一般来说，每一个文件、文件夹和Block需要占据150字节左右的空间，所以，如果你有100万个文件，每一个占据一个Block，你就至少需要300MB内存。当前来说，数百万的文件还是可行的，当扩展到数十亿时，对于当前的硬件水平来说就很痛苦了。因此由于海量元数据的因素，分布式文件系统对待海量小文件相对比较乏力。
其他
一些直接通过http访问的文件，比如脚本、CSS等。
要进行复杂的计算，比如计算要发射火箭到火星上去，顺便在宇宙飞船上要配置一桌麻将，需要计算有多少的能力，要有多少的着力点；