关于预期和实现：
在Google的面向大规模的数据密集型的分布式运用中，GFS都是关键和基础。同时，开源的hadoop File System 与GFS也是很相似的。
与传统的文件系统相比，GFS在设计上有以下几种特点：
一、组件失效被认为是常态，而不是意外
这很好理解，Google 的应用动辄数百甚至数千台机器，访问量又是巨大的。在系统集群工作期的任何时间点都有可能出现组件失效的事故，而且也要做好故障不能在短时间内被排除的准备。因此，在设计之初就考虑了多种优化机制来解决这个问题。
二、文件尺寸巨大
由于众所周知的原因，GFS的设计指标就是处理大规模和超大规模的数据集。因此，GFS的一些假设条件和参数都是适用于大规模数据计算的，在小规模计算上效率并不是太好。如：I/O操作和基本Block大小等，都是适配与大数据量的。
三、绝大多数文件修改操作都是采用文件尾部追加数据，而不是采用覆盖原有数据的形式
这点在大规模分布式系统上面是很重要的。由于带宽和距离的客观限制，我们并不能保证所有原子操作的顺序正确性。因此，数据的一致性很难得到保证。为每个数据保持多个副本，而不是保存最近的数据是必要的。通常master结点会选择所需要的数据。
四、应用程序和文件系统的API的协同设计提高了系统的灵活性
不太理解。但大致意思是，由于GFS的API与应用时同步的，使得接口设计的比较简洁，易于应用。
关于架构：
一个实现了GFS的集群包括一个Master结点（这里的单独的Master概念是指逻辑上只有一个Master组件，由于安全方面的原因，实际上包括二台物理主机）、多态Chunk服务器，并且同时被多台客户机所访问。如下图：
一、单一的Master结点：
Master结点管理所有的文件系统元数据，包括命名空间、访问控制信息、文件和Chunk映射信息、以及当前的Chunk的位置信息。Master结点还应该文件存储和读取的活动信息，如：Chunk租约（lease）、孤儿Chunk、Chunk位置的迁移等。
单一的Master结点的设计在设计上是清晰和明确的。Master结点通过存储全局性的数据来精确定位请求的Chunk的位置和状态，并指挥控制文件操作。但是这有一个很明显的缺点，就是系统必须保证尽量减少对Master结点的读取，以免Master成为系统的性能瓶颈。所以，Master本身并不存储数据，而是仅仅根据客户端提供的文件名和Chunk索引来定位Chunk服务器，然后客户在接下来的一段时间只需要与Chunk服务器打交道了。
二、Chunk的大小
Chunk的大小是GFS的一项关键性参数。
事实上，对所有的File System来说，元文件的大小都是影响性能的关键性参数。当文件块的大小过大时容易生成大量的文件块碎片，造成毁灭性的空间浪费。同时，每次文件操作（即使你只需1KB的数据），都必须传输较大的文件块，对带宽的要求比较高。而且，当多个关键性文件存储在同一个Chunk块时，在多客服同时访问时会造成麻烦。当文件块过小时，Master结点与Chunk服务器的通讯就会大大增加，这会大大增大Master端的压力。
Google File System选择的Chunk大小为64MB，这相对其他的File System来说应该是比较大的。选择这么大的Chunk也是有理由的。首先，降低了客户端和Master结点的通讯要求。一般对于一次客户端请求，只需一次与Master结点就能满足需求，减少了TCP连接建立花费的时间。其次，Chunk大，那么Chunk数量必定会少，易于客户端的缓存。第三，对于Master结点来说，内存就足够能缓存所有的元数据信息。
三、元数据
作为整个GFS的“管家”，Master服务器很存储多种数据，下面介绍最重要的三种：
文件和Chunk的命名空间：当客服请求fileName名字的文件，而又有多台Chunk主机保存有这个名字的文件时，区分不同的文件。
文件和Chunk的对应关系：只有拥有了这个数据，当客服请求某文件时，Master才知道应该返回那台Chunk服务器的地址。
每个Chunk副本的存放点：这个重要性同上
Master服务器的元数据都是保存在内存中的，所以Master结点的工作效率很高。通常，GFS会启动一个线程来周期性的扫描元数据，用于排错、垃圾回收、更新等。
四、操作日志
对于企业级的应用，操作日志的重要性不需要我多说了吧。
在GFS中，在关键性的元数据变更且确保持久性之后，会被记录到操作日志中去。这样做可以避免丢失部分客户端的操作信息。系统会定期做一个checkpoint来保存最新的日志（数据状态），一些机制会被采取来保证checkpoint不会影响正常的工作。
明天继续！！