互联网时代流行打造自己的系统，这个趋势应该是从Google开始的。

这是Twitter最近的Manhattan：https://blog.twitter.com/2014/manhattan-our-real-time-multi-tenant-distributed-database-for-twitter-scalehttp://gigaom.com/2014/05/12/3-lessons-in-database-design-from-the-team-behind-twitters-manhattan/ http://www.wired.com/2014/04/twitter-manhattan/

GFS与此前的很多分布式系统存在很大的不同。作为一个工程性产品，与此前的原型系统相比，差异更大。

1. 前提假设不同此前的很多系统都假设节点故障不那么频繁，而GFS则假设节点故障是家常便饭。这应该说是时代不同了，以前的分布式系统考虑的节点数比较少，而且每个节点都比较高端，出故障的几率相对较小。GFS采用的则是普通的商用软硬件，出错的几率偏大。因此需要在系统中考虑持续监测，错误监测，容错以及自动恢复等功能。

2. 业务需求不同不同的系统对业务需求和支持的应用场景都有一定的假设。而GFS则源自Google内部业务对分布式文件系统的需求，做了很多有针对性的设计。例如文件一般比较大，所以IO的大小和存储的块大小都需要有针对性的选择。文件的写操作大多是追加写而不是覆盖写，文件的读操作大多是顺序大块的读，因此客户端缓存数据也没什么必要了。

3. 支持的功能不同传统的文件系统需要支持的典型功能有名字空间、权限控制、Quota、快照、备份、POSIX API等等。分布式文件系统则需要更多的考虑可用性、容错性、扩展性等。GFS如果要实现大多数文件系统的功能，势必会增加系统的复杂度，因此对支持的功能做了很多权衡。当然，简化的API势必要求应用程序做出相应的配合，这看起来是增加了应用开发的难度，但也正是此类系统可以更高效的完成任务的优势所在。

总之，GFS是一个满足特定应用场景需求的，非通用的分布式文件系统。这也是Web时代很多系统的特点：不求大而全。

下面列出一些值得注意和思考的问题。

1. 体系结构单一的Master和一大堆Chunk Server。
2. Chunk尺寸为什么选择64MB。
3. Master节点元信息的内存结构。Chunk的位置选择。操作日志（事务日志）。名字空间管理。副本的放置。数据重分布。空间回收。
4. 一致性模型5. 操作流程租期，读，写，追加，快照。
5. 容错和问题诊断Master的单点和HA。Checksum和数据完整性。日志，诊断工具。
6. 实现中遇到的坑

可以看到，GFS中采用的多半是以前已经存在的技术。但是这并不妨碍它成为一个成功的软件。