首先明确一点，分布式文件系统比如NFS，AFS，还有GFS与现在流行的分布式版本控制系统比如svn，git不同[主要在并发操作和同步异步机制上的区别]。简而言之，分布式版本控制系统构建在分布式文件系统之上，文件系统只完基本的同步和并发操作，相当于API，然后版本控制系统再指定自己的详细逻辑来处理并发和同步问题，弄清这点，才能理解为什么文件系统并不纠结与处理复杂的并发和同步操作。

Google File System是第二次读，确是第一次正式读，之前的第一次阅读对于很多概念和知识还很模糊所以只是走马观花的看了以下，这次对于很多东西有了更深的理解。但是需要说明的是，这次看完还是有很多地方不能完全理解，毕竟没有完整做过类型的项目，期待后续的学习，然后再次阅读能有更深的理解。

第二次阅读的理解

  1. 每个分布式系统，或者说每个系统都有自己存在的意义也就是系统的目标，这个目标应该是在设计系统的时候最先确定的，因为根据不同的目标设计的思路可能天差地别。比如，一个应用于高并发的环境中的分布式系统，其优先解决的是在机器节点数量增加的情况下，如何处理并发问题并保证正确性和性能。再比如一个经常出错的环境下[宕机或者硬件问题或者网络环境不佳造成的数据丢失等等]，如何容错和从错误中迅速回复就是首要解决的问题。

  2. GFS的主要考虑的环境有：1)整个大型的分布式文件系统，有大量廉价或者说一般的机器组成其性能基本处于家用或者高于家用一点点。所以考虑到大量的这样的机器和他们的性能，所以假设整个系统在任何时候都存在问题或者错误，所以如何容错和恢复就是一个关键问题了。2)整个系统的读写基本上都是大数据的连续读写所以大部分的都是append操作而overwrite操作很少，小数据的随机读写也是小部分的。3)系统里基本都是大文件，所以管理成千上万kb级文件的方式已经不适用了。所以整个系统的设计都是从这三个大的目标出发的。

  3. 关于Cache。Master，ChunkServer还有Client都不Cache数据。首先Master不cache数据，因为整个GFS的设计就是避免Master参与读写操作，它的角色只是一个manager或者叫coordinator更准确一些。其次，客户端缓存数据并有没有太大的作用，因为大部分都是流式读取一个大数据根本不需要缓存，要么就是数据太大无法缓存，所以客户端干脆就不用缓存。但是客户端cache一些metadata因为这样不用频繁地和master交互[比如cache了chunk存在具体那个chunkserver就可以直接访问chunkserver]。最后chunkserver也不需要设计cache机制，因为按照文章介绍所有机器都是linux系统，它本身就会cache最近最常访问的文件[LRU机制]。

未完待续。。。