sina
Google File System，一个适用于大规模分布式数据处理相关应用的，可扩展的分布式文件系统。
GFS 提供了常见的文件系统的接口，文件是通过pathname 来通过目录进行分层管理的。我们支持的一些常见操作：create,delete,open,close,read，write 等文件操作。另外，GFS 有snapshot，record append 等操作。snapshort 创建一个文件或者一个目录树的快照，这个快照的耗费比较低。record append 允许很多个客户端同时对一个文件增加数据，同时保证每一个客户端的添加操作的原子操作性。这个对于多路合并操作和多个客户端同时操作的生产者/消费者队列的实现非常有用，它不用额外的加锁处理。
如上图所示，GFS 集群由一个单个的master 和好多个chunkserver（块服务器）组成，GFS 集群会有很多客户端client 访问。每一个节点都是一个普通的Linux 计算机，运行的是一个用户级别（user-level）的服务器进程。只要机器资源允许，并且允许不稳定的应用代码导致的低可靠性，我们就可以运行chunkserver 和client 可以运行在同一个机器上。
在 GFS 下，每一个文件都拆成固定大小的chunk(块)。每一个块都由master 根据块创建的时间产生一个全局唯一的以后不会改变的64 位的chunk handle 标志。chunkservers 在本地磁盘上用Linux文件系统保存这些块，并且根据chunk handle 和字节区间，通过Linux 文件系统读写这些块的数据。出于可靠性的考虑，每一个块都会在不同的chunkserver 上保存备份。缺省情况下，我们保存3 个备份，不过用户对于不同的文件namespace 区域，指定不同的复制级别。
master 负责管理所有的文件系统的元数据。包括namespace，访问控制信息，文件到chunk 的映射关系，当前chunk 的位置等等信息。master 也同样控制系统级别的活动，比如chunk 的分配管理，孤点chunk 的垃圾回收机制，chunkserver 之间的chunk 镜像管理。master 和这些chunkserver 之间会有定期的心跳线进行通讯，并且心跳线传递信息和chunckserver 的状态。
这里我们简单介绍一下上图 中的读取操作。首先，客户端把应用要读取的文件名和偏移量，根据固定的chunk 大小，转换成为文件的chunk index。然后向master 发送这个包含了文件名和chunkindex的请求。master 返回相关的chunk handle 以及对应的位置。客户端cache 这些信息，把文件名和chunkindex 作为cache 的关键索引字。
于是这个客户端就像对应的位置的chunkserver 发起请求，通常这个会是离这个客户端最近的一个。请求给定了chunk handle 以及一个在这个chunk 内需要读取得字节区间。在这个chunk 内，再次操作数据将不用再通过客户端-master 的交互，除非这个客户端本身的cache 信息过期了，或者这个文件重新打开了。实际上，客户端通常都会在请求中附加向master 询问多个chunk 的信息，master于是接着会立刻给这个客户端回应这些chunk 的信息。这个附加信息是通过几个几乎没有任何代价的客户端-master 的交互完成的。
chunk 的大小是一个设计的关键参数。选择一个很大的chunk 大小提供了一些重要的好处，减少了客户端和master 的交互，因为在同一个chunk 内的读写操作只需要客户端初始询问一次master 关于chunk 位置信息就可以了。可以通过维持一个到chunkserver 的TCP 长连接来减少网络管理量，减少了元数据在master 上的大小，这个使得我们可以把元数据保存在内存。
元数据：
master 节点保存这样三个主要类型的数据：文件和chunk 的namespace，文件到chunks 的映射关系，每一个chunk 的副本的位置。头两个类型（namepspaces 和文件到chunk 的映射）同时也是由在master 本地硬盘的记录所有变化信息的operation log (操作记录保存了关键的元数据变化历史记录。它是GFS 的核心。不仅仅因为这是唯一持久化的元数据记录，而且也是因为操作记录也是作为逻辑时间基线，定义了并行操作的顺序)来持久化保存的，这个记录也会在远端机器上保存副本。通过log，在master 宕机的时候，我们可以简单，可靠的恢复master 的状态。master 并不持久化保存chunk 位置信息。相反，他在启动地时候以及chunkserver 加入集群的时候，向每一个chunkserver 询问他的chunk 信息。
操作记录（operation log）
我们把这个日志文件保存在多个不同的主机上，并且只有当刷新这个相关的操作记录到本地和远程磁盘之后，才会给客户端操作应答。master 可以每次刷新一批日志记录，以减少刷新和复制这个日志导致的系统吞吐量。
为了减少启动时间，我们必须尽量减少操作日志的大小。master 在日志增长超过某一个大小的时候，执行checkpoint 动作，卸出自己的状态，这样可以使下次启动的时候从本地硬盘读出这个最新的checkpoint，然后反演有限记录数。
checkpoint 是一个类似B-树的格式，可以直接映射到内存，而不需要额外的分析。这更进一步加快了恢复的速度，提高了可用性。因为建立一个checkpoint 可能会花一点时间，于是我们这样设定master 的内部状态，就是说新建立的checkpoint 可以不阻塞新的状态变化。master 切换到一个新的log 文件，并且在一个独立的线程中创建新的checkpoint。新的checkpoint 包含了在切换到新log 文件之前的状态变化。当这个集群有数百万文件的时候，创建新的checkpoint 会花上几分钟的时间。当checkpoint 建立完毕，会写到本地和远程的磁盘。
对于 master 的恢复，只需要最新的checkpoint 以及后续的log 文件。旧的checkpoint 及其log 文件可以删掉了，虽然我们还是保存几个checkpoint 以及log，用来防止比较大的故障产生。在checkpoint的时候得故障并不会导致正确性受到影响，因为恢复的代码会检查并且跳过不完整的checkpoint。
一致性模型
文件名字空间的改变（比如，文件的创建）是原子操作。他们是由master 来专门处理的。名字空间的锁定保证了操作的原子性以及正确性；master 的操作日志定义了这些操作的全局顺序。
namespace 管理及锁定
GFS 从逻辑上是通过一个查找路径名到元数据映射表的方式来体现namespace 的。通过前缀压缩，这个表可以有效地在内存中存放。每一个namespace 树种的节点（不论是绝对文件名还是绝对目录名），都有一个相关的读写锁。
副本位置
GFS 集群是在不止一个级别上的多级别的高度分布的系统。通常由好几百台分布在很多机架上的chunkserver 组成。这些chunkserver 可能被相同或者不同的机架的几百台客户端轮流访问。两个机架上的两台机器可能会跨越不止一个网络交换机。此外，机架的入口带宽或者出口带宽往往会比在机架内的机器聚合带宽要小。多级别的分布凸现了一个独特的要求，为了可扩展性，可靠性，以及可用性要把数据进行分布。
数据完整性
每一个chunkserver 都是用checksum 来检查保存数据的完整性。通常一个GFS 集群都有好几百台机器以及几千块硬盘，磁盘损坏是很经常的事情，在数据的读写中经常出现数据损坏。我们可以通过别的chunk 副本来解决这个问题，但是如果跨越chunkserver 比较这个chunk的内容来决定是否损坏就很不实际。进一步说，允许不同副本的存在;在GFS 更改操作的语义上，特别是早先讨论过的原子纪录增加的情况下，并不保证byte 级别的副本相同。因此，每一个chunkserver上必须独立的效验自己的副本的完整性，并且自己管理checksum。
我们把一个chunk 分成64k 的块。每一个都有相对应的32 位的checksum。就像其他的元数据一样，checksum 是在内存中保存的，并且通过分别记录用户数据来持久化保存。对于读操作来说，在给客户端或者chunkserver 读者返回数据之前，chunkserver 效验要被读取的数据所在块的checksum。因此chunkserver 不会把错误带给其他设备。如果一个块的checksum 不正
确，chunkserver 会给请求者一个错误，并且告知master 这个错误。收到这个应答之后，请求者应当从其他副本读取这个数据，master 也会安排从其他副本来做克隆。当一个新的副本就绪后，master会指挥刚才报错的chunkserver 删掉它刚才错误的副本。checksum 对于读取性能来说，在几方面有点影响。因为大部分的读取操作都分布在好几个block 上，我们只需要额外的多读取一小部分相关数据进行checksum 检查。GFS 客户端代码通过每次把读取操作都对齐在block 边界上，来进一步减少了这些额外的读取。此外，在chunkserver 上的checksum的查找和比较不需要附加的I/O，checksum 的计算可以和I/O 操作同时进行。
checksum 的计算是针对添加到chunk 尾部的写入操作作了高强度的优化（和改写现有数据不同），因为它们显然占据主要工作任务。我们增量更新关于最后block 的checksum 部分，并且计算添加操作导致的新的checksum block 部分。即使是某一个checksum 块已经损坏了，但是我们在写得时候并不立刻检查，新的checksum 值也不会和已有数据吻合，下次对这个block 的读取的时候，会检查出这个损坏的block。
另一方面，如果写操作基于一个已有的chunk（而不是在最后追加），我们必须读取和效验被写得第一个和最后一个block，然后再作写操作，最后计算和写入新的checksum。如果我们不效验第一个和最后一个被写得block，那么新的checksum 可能会隐藏没有改写区域的损坏部分。
在 chunkserver 空闲的时候，他扫描和效验每一个非活动的chunk 的内容。这使得我们能够检查不常用的chunk 块的完整性。一旦发现这样的块有损坏，master 可以创建一个新的正确的副本，然后把这个损坏的副本删除。这个机制防止了非活动的块损坏的时候，master 还以为这些非活动块都已经有了足够多的副本。
