Google文件系统

在设计一个满足我们需求的文件系统时，我们以一些充满了挑战和机遇的假设作为指南， 之前我们曾间接的提到过一些关键的点，现在我们把这些假设再详细的列出来。

一、系统是由廉价的经常失败的商品化组件构建而来。必须进行经常性的监控和检测， 容错，并且能够从组件失败中迅速的恢复，这些都应该像是例行公事。

二、系统存储了适度个数的大文件。我们期望有数百万个文件，每个100mb或者更大。 上GB的文件大小应该是很普通的情况而且能被有效的管理。小文件也应该被支持， 但我们不需要为它们进行优化。

三、工作负载主要由两种类型的读组成：大的顺序流式读取和小的随机读取。在大的 流式读取中，单个操作通常要读取数百k，甚至1m或者更大的数据。来自于同一个客户端 的连续读取，通常读完文件的一个连续区域。小的随机读取通常在某个任意的偏移位置 读取几kb的数据。具有性能意识的应用程序会把这些小的随机读取按批次，排序使得读取 可以稳步的穿越整个文件而不是来回读取。

四、工作负载有很多大的对文件数据的append操作，通常操作的大小类似与读操作。一旦 写完，件就很少改变，在文件内部的随机写操作可以被支持，但是性能不必是很高的。

五、系统对于良好定义的多个客户端对相同文件的并行append操作必须提供有效的实现。 我们的文件通常是用来作为生产者消费者队列或者进行多路归并。数百个生产者(每个 机器上运行一个)将会对同一个文件进行append。因此具有最小化同步开销的原子性是 必要的。文件之后可能会被读取，或者消费者可能并行的读取这个文件。

六、高的持续带宽比低延时更重要。我们大部分的目标应用都希望得到高速的批量数据处理 速度，很少有对于单个的读写有严格的响应时间需求。

GFS提供一个熟悉的文件系统接口，尽管它并没有实现一个诸如POSIX那样的标准API。文件 通过目录进行层次化组织，通过路径来标识文件。支持常见的那些文件操作：create, delete,open,close,read,write。

另外，GFS还具有快照和append操作。快照以很低的开销创建一个文件或者目录数的拷贝。 Append操作允许多个客户端向同一个文件并发的操作，同时保证每个独立客户端的append 操作的原子性。这对于实现多路归并的结果以及生成者消费者队列很有帮助，这样客户端 不需要额外的锁操作就可以并行的append。我们发现这种文件类型，对于构建大型的分布式 应用简直就是无价之宝。快照和append操作将会在3.4和3.3分别讨论。

一个GFS集群由一个master和多个chunkserver组成，可以被多个client访问，如图1所示。

它们都是一个运行着用户级服务进程的商品化linux机器。可以很容易的在同一台机器上 运行一个chunkserver和client，只要机器资源允许以及由于运行可能的片状应用程序代码 带来的低可靠性是可以接受的。

文件被划分成固定大小的chunk。每个chunk是由chunk创建时由master分配的一个不可变的 全局唯一的64bit句柄来标识。Chunkserver将chunk作为linux文件存储在本地，对于chunk 数据的读写通过chunk的handle和字节边界来表示。为了可靠性，每个chunk存储在多个 chunkserver上。尽管用户可以为不同文件名字空间区域指定不同的备份级别，默认地我们 存储三个备份。

Master维护所有的文件系统元数据。包括名字空间，访问控制信息，文件与chunk的映射 信息，chunk的当前位置。它也控制系统范围内的一些活动，比如chunk租赁管理，僵死 chunk的垃圾回收，chunkserver间的chunk迁移。Master与chunkserver通过心跳信息进行 周期性的通信，以发送指令和收集chunkserver的状态。

应用程序链接的GFS客户端代码实现了文件系统API以及代表应用程序与master和 chunkserver进行通信以读写数据。客户端如果需要操作元数据则需要与master通信，但是 所有的纯数据通信直接与chunksever通信。我们没有提供POSIX API，因此也就不需要与 linux vnode layer关联。

客户端或者chunkserver都不会进行文件数据缓存。客户端缓存只能得到很少的好处，因为 大部分的应用需要直接读取整个大文件或者工作集合太大根本无法缓存。没有cache简化了 客户端和整个系统，因为不需要考虑缓存一致性问题(实际上客户端会缓存元数据)。 Chunkserver不需要进行文件数据缓存，是因为chunk是作为本地文件存储，这样linux自身 会将那些经常访问的数据进行缓存。

只有一个master大大简化了我们的设计，而且使得master可以利用全局信息对chunk的放置 和备份进行更好的判断。然而，我们必须最小化它在读写中的参与性，使得它不会成为一个 瓶颈。Client永远不会通过master读取文件数据，它只是问master它应该同哪个 chunkserver联系。并且client将这些信息在有限的时间段内进行缓存，直接与chunksever 交互进行很多后续的操作。

根据图1，我们简单解释一些一个读操作的交互过程：首先，通过固定大小的chunk，客户端 将应用程序中标识的文件名和offset转换为chunk的index。然后给master发送一个包含 文件名和chunk index的请求，master返回相应的chunk的handle和所有备份的位置。客户端 以文件名和chunk index为key将这条信息进行缓存。

然后客户端给其中一个备份发送一个请求，通常是最近的那个。请求标识了chunk 的handle 以及在那个chunk内的字节边界。直到缓存信息过期或者重新打开文件之前，对于相同 chunk的后续读操作就不需要client-master的通信了。事实上，客户端通常在一个请求中 查询多个chunk的信息，master也可以将这些被请求的多个chunk的信息包裹在一块进行 返回。这种特别的信息，并没有额外的花费就避免了未来的client-master的多次通信。

Chunk大小是一个关键的设计参数。我们选择了64MB，远远大于现有的文件系统块。每个 chunk的副本作为普通的linux文件存储在chunkserver上，如果需要才会进行扩展。Lazy 空间分配避免了内部碎片造成的空间浪费，很可能最大的碎片有向一个chunk那么大。

大的chunk size提供了几个重要的优势。首先，降低了client与sever的交互需求，因为在 相同chunk上的读写只需要一个初始化请求就可以从master得到chunk的位置信息。这个减少 对于我们的应用负载是非常明显的，因为我们应用大部分需要顺序的读写整个大文件。即使 对于小的随机读取，客户端也可以很容易的缓存一个几TB工作集的所有chunk的位置信息。 其次，由于chunk很大，那么客户端就很有可能在一个给定的chunk上执行更多的操作，这样 可以将一个与chunkserver的TCP连接保持更长的时间，这就减少了网络开销。再者，降低了 存储在master上的元数据大小。这样就允许我们将元数据存放在内存中，反过来就带来了 我们将在2.6.1中讨论的其他优势。

另一方面，大的chunk size，即使采用了lazy空间分配，也有它的缺点。小的文件可能只有 少数几个chunk，或许只有一个。如果很多的client都需要访问这个文件，这样那些存储了 这些chunk的chunkserver就会变成热点。实际中，热点还没有成为一个主要的考虑点因为 我们的应用绝大部分都是在顺序读大的多chunk文件。

然而，当GFS第一次使用在一个批处理队列系统时，热点确实出现了：一个可执行文件作为 一个chunk的文件写到GFS，然后同时在数百台机器上开始执行。存储了该可执行文件的 那些chunkserver被数百个并发请求瞬间变成超载。我们通过更高的备份级别存储这样的 可执行文件以及减慢队列系统的应用程序启动时间解决了这个问题。一个潜在的长远的 解决方案是在这种情况下，允许客户端从其他客户端读取数据。

Master存储了三个主要类型的元数据：文件和chunk名字空间，文件到chunk的映射信息， 每个chunk的备份的位置。所有的元数据都保存在master的内存中。前两种类型还通过将 更新操作的日志保存在本地硬盘和备份在远程机器来保持持久化。使用log允许我们简单 可靠地更新master的状态，不用担心当master crash的时候的不一致性。Master并没有 永久保存chunk的位置信息，而是在master启动或者某个chunkserver加入集群时，它会向 每个chunkserver询问它的chunks信息。

GFS使用的一个放松的一致性模型不但很好的支持了我们的高度分布式的应用，而且实现 起来也相对简单和有效率。我们现在讨论GFS所提供的保证以及它们对应用程序的意味着 什么。我们也会讲述GFS如何维护这些保证，但是会将具体的细节留到其他论文里讲述。

一个变更是指一个改变chunk的内容或者元信息的操作，比如写操作或者append操作。每个 变更都需要在所有的副本上执行。我们使用租约来保持多个副本间变更顺序的一致性。 Master授权给其中的一个副本一个该chunk的租约，我们把它叫做主副本。这个主副本为 针对该chunk的所有变更的选择一个执行顺序，然后所有的副本根据这个顺序执行变更。 因此，全局的变更顺序首先是由master选择的租约授权顺序来确定的(可能有多个chunk需要 进行修改)，而同一个租约内的变更顺序则是由那个主副本来定义的。

租约机制是为了最小化master的管理开销而设计的。一个租约有一个初始化为60s的超时 时间设置。然而只要这个chunk正在变更，那个主副本就可以向master请求延长租约。这些 请求和授权通常是与master和chunkserver间的心跳信息一起发送的。有时候master可能 想在租约过期前撤销它(比如，master可能想使对一个正在重命名的文件的变更无效)。即使 master无法与主副本进行通信，它也可以在旧的租约过期后安全的将租约授权给另一个新的 副本。

如图2，我们将用如下的数字标识的步骤来表示一个写操作的控制流程。

1/. client向master询问那个chunkserver获取了当前chunk的租约以及其他副本所在的 位置。如果没有人得到租约，master将租约授权给它选择的一个副本。

2/. master返回该主副本的标识符以及其他副本的位置。Client为未来的变更缓存这个 数据。只有当主副本没有响应或者租约到期时它才需要与master联系。

3/. client将数据推送给所有的副本，client可以以任意的顺序进行推送。每个 chunkserver会将数据存放在内部的LRU buffer里，直到数据被使用或者过期。通过将 控制流与数据流分离，我们可以通过将昂贵的数据流基于网络拓扑进行调度来提高性能， 而不用考虑哪个chunkserver是主副本。3.2节更深入地讨论了这点。

4/. 一旦所有的副本接受到了数据，client发送一个写请求给主副本，这个请求标识了 先前推送给所有副本的数据。主副本会给它收到的所有变更(可能来自多个client)安排 一个连续的序列号来进行必需的串行化。它将这些变更根据序列号应用在本地副本上。

5/. 主副本将写请求发送给所有的次副本，每个次副本以与主副本相同的串行化顺序应用 这些变更。

6/. 所有的次副本完成操作后向主副本返回应答

7/. 主副本向client返回应答。任何副本碰到的错误都会返回给client。出现错误时，该写 操作可能已经在主副本以及一部分次副本上执行成功。(如果主副本失败，那么它不会安排 一个序列号并且发送给其他人)。客户端请求将会被认为是失败的，被修改的区域将会处在 非一致状态下。我们的客户端代码会通过重试变更来处理这样的错误。它会首先在3-7 步骤间进行一些尝试后在重新从头重试这个写操作。

如果应用程序的一个写操作很大或者跨越了chunk的边界，GFS client代码会将它转化为 多个写操作。它们都会遵循上面的控制流程，但是可能会被来自其他client的操作插入 或者覆盖。因此共享的文件区域可能会包含来自不同client的片段，虽然这些副本是 一致的，因为所有的操作都按照相同的顺序在所有副本上执行成功了。但是文件区域 会处在一种一致但是未定义的状态，正如2.7节描述的那样。

为了更有效的使用网络我们将数据流和控制流分离。控制流从client到达主副本，然后到达 其他的所有次副本，而数据则是线性地通过一个仔细选择的chunkserver链像流水线那样 推送过去的。我们的目标是充分利用每个机器的网络带宽，避免网络瓶颈和高延时链路， 最小化数据推送的延时。

为了充分利用每个机器的网络带宽，数据通过chunkserver链线性的推送过去而不是以 其他的拓扑进行分布比如树型。因此每个机器的带宽可以全部用来发送数据而不是为多个 接受者进行切分。

为了尽可能的避免网络瓶颈和高延时链路，每个机器向网络中还没有收到该数据的最近的 那个机器推送数据。假设client将数据推送给S1- S4，它会首先将数据推送给最近的 chunkserver假设是S1，S1推送给最近的，假设S2，S2推送给S3，S4中离他最近的那个。 我们网络拓扑足够简单，以至于距离可以通过IP地址估计出来。

最后为了最小化延时，我们通过将TCP数据传输进行流水化。一旦一个chunkserver收到 数据，它就开始立即往下发送数据。流水线对我们来说尤其有用，因为我们使用了一个 全双工链路的交换网络。立即发送数据并不会降低数据接受速率。如果没有网络拥塞， 向R个副本传输B字节的数据理想的时间耗费是B/T+RL,T代表网络吞吐率，L是机器间的 网络延时。我们的网络连接是100Mbps(T),L远远低于1ms，因此1MB的数据理想情况下需要 80ms就可以完成。

GFS提供一个原子性的append操作叫做record append(注意这与传统的append操作也是 不同的)。在传统的写操作中，用户指定数据需要写的便宜位置。对于相同区域的并行写 操作是不可串行的：该区域的末尾可能包含来自多个client的数据片段。但在一个record append操作中，client唯一需要说明的只有数据。GFS会将它至少原子性地append到文件中 一次，append的位置是由GFS选定的，同时会将这个位置返回给client。这很类似于unix 文件打开模式中的O_APPEND，当多个写者并发操作时不会产生竞争条件。

Record append在我们的分布式应用中被大量的使用。很多在不同机器的client并发地向 同一个文件append。如果使用传统的写操作，client将需要进行复杂而又昂贵的同步化 操作，比如通过一个分布式锁管理器。在我们的工作负载中，这样的文件通常作为一个 多生产者/单消费者队列或者用来保存来自多个不同client的归并结果。

Record append是一种类型的变更操作，除了一点在主副本上的额外的逻辑外依然遵循3.1 节的控制流。Client将所有的数据推送给所有副本后，它向主副本发送请求。主副本检查 将该记录append到该chunk是否会导致该chunk超过它的最大值(64MB)。如果超过了，它就 将该chunk填充到最大值，告诉次副本做同样的工作，然后告诉客户端该操作应该在下一个 trunk上重试。(append的Record大小需要控制在最大trunk大小的四分之一以内，这样可以 保证最坏情况下的碎片可以保持在一个可以接受的水平上 )。如果记录可以没有超过最大 尺寸，就按照普通情况处理，主副本将数据append到它的副本上，告诉次副本将数据写在 相同的偏移位置上，最后向client返回成功应答。

如果record append在任何一个副本上失败，client就会重试这个操作。这样，相同chunk的 多个副本就可能包含不同的数据，这些数据可能包含了相同记录的整个或者部分的重复值。 GFS并不保证所有的副本在位级别上的一致性，它只保证数据作为一个原子单元最少写入 一次。这个属性是由如下的简单观察推导出来的，当操作报告成功时，数据肯定被写入到 某个trunk的所有副本的相同偏移位置上。此后，所有的副本至少达到了记录尾部的大小， 因此未来的记录将会被放置在更高的便宜位置，或者是另一个不同的chunk，即使另一个 副本变成了主副本。在我们的一致性保证里，record append操作成功后写下的数据区域 是已定义的(肯定是一致的)，然而介于其间的数据则是不一致的(因此也是未定义的)。 我们的应用程序可以处理这样的不一致区域，正如我们在2.7.2里讨论的那样。

快照操作可以非常快速的保存文件或者目录树的一个拷贝，同时可以最小化对于正在执行的 变更操作的中断。用户经常用它来创建大数据集的分支拷贝，以及拷贝的拷贝……。或者用来 创建检查点，以实验将要提交的拷贝或者回滚到更早的状态。

像AFS，我们使用标准的写时拷贝技术来实现快照。当master收到一个快照请求时，它首先 撤销将要进行快照的那些文件对应的chunk的所有已发出的租约。这就使得对于这些chunk的 后续写操作需要与master交互来得到租约持有者。这就首先给master一个机会创建该 chunk的新的拷贝。

当这些租约被撤销或者过期后，master将这些操作以日志形式写入磁盘。然后复制该文件 或者目录树的元数据，然后将这些日志记录应用到内存中的复制后的状态上，新创建的 快照文件与源文件一样指向相同的chunk。

当client在快照生效后第一次对一个chunk C进行写入时，它会发送请求给master找到当前 租约拥有者。Master注意到对于chunk C的引用计数大于1。它延迟回复客户端的请求，选择 一个新的chunk handle C`。然后让每个拥有C的那些chunkserver创建一个新的叫做C`的 chunk。通过在相同的chunkserver上根据原始的chunk创建新chunk，就保证了数据拷贝是 本地的，而不是通过网络(我们的硬盘比100Mbps网络快大概三倍)。这样，对于任何 chunk的请求处理都没有什么不同：master为新才chunk C`的副本中的一个授权租约， 然后返回给client，这样它就可以正常的写这个chunk了，client不需要知道该chunk实际上 是从一个现有的chunk创建出来的。

很多master操作都需要花费很长时间：比如，一个快照操作要撤销该快照所包含的chunk的 所有租约。我们并不想耽误其他运行中的master操作，因此我们允许多个操作同时是活动 的，通过在名字空间区域使用锁来保证正确的串行化。

不像传统的文件系统，GFS的目录并没有一种数据结构用来列出该目录下所有文件，而且也 不支持文件或者目录别名(像unix的硬链接或者软连接那样)。GFS在逻辑上通过一个路径 全称到元数据映射的查找表来表示它的名字空间。通过采用前缀压缩，这个表可以有效地 在内存中表示。名字空间树中的每个节点(要么是文件的绝对路径名称要么是目录的)具有 一个相关联的读写锁。

每个master操作在它运行前，需要获得一个锁的集合。比如如果它想操作 /d1/d2…/dn/leaf，那么它需要获得/d1,/d1/d2……/d1/d2…/dn这些目录的读锁，然后才能 得到路径/d1/d2…/dn/leaf的读锁或者写锁。Leaf可能是个文件或者目录，这取决于具体的 操作。

我们现在解释一下，当为/home/user创建快照/save/user时，锁机制如何防止文件 /home/user/foo被创建。快照操作需要获得在/home上的读锁，以及/home/user和 /save/user上的写锁。文件创建需要获得在/home和/home/user上的读锁，以及在 /home/user/foo上的写锁。这两个操作将会被正确的串行化，因为它们试图获取在 /home/user上的相冲突的锁。文件创建并不需要父目录的写锁，因为实际上这里并没有 “目录”或者说是类似于inode的数据结构，需要防止被修改。读锁已经足够用来防止父目录 被删除。

这种锁模式的一个好处就是它允许对相同目录的并发变更操作。比如多个文件的创建可以 在相同目录下并发创建：每个获得该目录的一个读锁，以及文件的一个写锁。目录名称上的 读锁足够可以防止目录被删除，重命名或者快照。文件名称上的写锁将会保证重复创建相同 名称的文件的操作只会被执行一次。

因为名字空间有很多节点，所以读写锁对象只有在需要时才会被分配，一旦不再使用用就 删除。为了避免死锁，锁是按照一个一致的全序关系进行获取的：首先根据所处的名字 空间树的级别，相同级别的则根据字典序。

GFS在多个层次上都具有高度的分布式。它拥有数百个散步在多个机柜中的chunkserver。 这些chunkserver又可以被来自不同或者相同机柜上的client访问。处在不同机柜的 机器间的通信可能需要穿过一个或者更多的网络交换机。此外，进出一个机柜的带宽可能会 小于机柜内所有机器的带宽总和。多级的分布式带来了数据分布式时的扩展性，可靠性和 可用性方面的挑战。

Chunk的备份放置策略服务于两个目的：最大化数据可靠性和可用性，最小化网络带宽的 使用。为了达到这两个目的，仅仅将备份放在不同的机器是不够的，这只能应对机器或者 硬盘失败，以及最大化利用每台机器的带宽。我们必须在机柜间存放备份。这样能够保证 当一个机柜整个损坏或者离线(比如网络交换机故障或者电路出问题)时，该chunk的存放在 其他机柜的某些副本仍然是可用的。这也意味着对于一个chunk的流量，尤其是读取操作 可以充分利用多个机柜的带宽。另一方面，写操作需要在多个机柜间进行，但这是我们可以 接受的。

Chunk副本的创建主要有三个原因：chunk的创建，重备份，重平衡。

当master创建一个chunk时，它将初始化的空的副本放置在何处。它会考虑几个因素： 1.尽量把新的chunk放在那些低于平均磁盘空间使用值的那些chunkserver上。随着时间的 推移，这会使得chunkserver的磁盘使用趋于相同; 2.尽量限制每个chunkserver上的最近的 文件创建数，虽然创建操作是很简单的，但是它后面往往跟着繁重的写操作，因为chunk的 创建通常是因为写者的需要而创建它。在我们的一次append多次读的工作负载类型中，一旦 写入完成，它们就会变成只读的。3.正如前面讨论的，我们希望在机柜间存放chunk的副本

当chunk的可用备份数低于用户设定的目标值时，Master会进行重复制。有多个可能的原因 导致它的发生：chunkserver不可用，chunkserver报告它的某个备份已被污染，一块硬盘 由于错误而不可用或者用户设定的目标值变大了。需要重复制的chunk根据几个因素确定 优先级。一个因素是它与备份数的目标值差了多少，比如我们给那些丢失了2个副本的 chunk比丢失了1个的更高的优先级。另外，比起最近被删除的文件的chunk，我们更想备份 那些仍然存在的文件的chunk(参考4.4节)。最后了，为了最小化失败对于运行中的应用 程序的影响，我们提高那些阻塞了用户进度的chunk的优先级。

Master选择最高优先级的chunk，通过给某个chunkserver发送指令告诉它直接从一个现有 合法部分中拷贝数据来进行克隆。新备份的放置与创建具有类似的目标：平均磁盘使用， 限制在单个chunkserver上进行的clone操作数，使副本存放在不同机柜间。为了防止 clone的流量淹没client的流量，master限制整个集群已经每个chunkserver上处在活动 状态的clone操作数。另外每个chunkserver还会限制它用在clone操作上的带宽，通过控制 它对源chunkserver的读请求。

最后，master会周期性的对副本进行重平衡。它检查当前的副本分布，然后为了更好的 磁盘空间使用和负载瓶颈，将副本进行移动。而且在这个过程中，master是逐步填充一个 新的chunkserver，而不是立即将新的chunk以及大量沉重的写流量使他忙的不可开交。 对于一个新副本的放置，类似于前面的那些讨论。另外，master必须选择删除哪个现有的 副本。通常来说，它更喜欢那些存放在低于平均磁盘空闲率的chunkserver上的chunk，这样 可以使磁盘使用趋于相等。

文件删除后，GFS并不立即释放可用的物理存储。它会将这项工作推迟到文件和chunk级别的 垃圾回收时做。我们发现，这种方法使得系统更简单更可靠。

如果chunkserver失败或者在它停机期间丢失了某些更新，chunk副本就可能变为过期的。 对于每个chunk，master维护一个版本号来区分最新和过期的副本。

只要master为一个chunk授权一个新的租约，那么它的版本号就会增加，然后通知副本进行 更新。在一致的状态下，Master和所有副本都会记录这个新的版本号。这发生在任何client 被通知以前，因此也就是client开始向chunk中写数据之前。如果另一个副本当前不可用， 它的chunk版本号就不会被更新。当chunkserver重启或者报告它的chunk和对应的版本号的 时候，master会检测该chunkserver是否包含过期副本。如果master发现有些版本号大于 它的记录，master就认为它在授权租约时失败了，所以采用更高的版本号的那个进行更新。

Master通过周期性的垃圾回收删除过期副本。在此之前，对于客户端对于该chunk的请求 master会直接将过期副本当作根本不存在进行处理。作为另外一种保护措施，当master 通知客户端那个chunkserver包含某chunk的租约或者当它在clone操作中让chunkserver从 另一个chunkserver中读取chunk时，会将chunk的版本号包含在内。当clinet和 chunkserver执行操作时，总是会验证版本号，这样就使得它们总是访问最新的数据。

在GFS的数百台服务器中，在任何时间总是有一些是不可用的。我们通过两个简单有效的 策略来保持整个系统的高可用性：快速恢复和备份。

每个chunkserver通过校验和来检测存储数据中的损坏。GFS集群通常具有分布在几百台 机器上的数千块硬盘，这样它就会经常出现导致数据损坏或丢失的硬盘失败。我们可以 从chunk的其他副本中恢复被损坏的数据，但是如果通过在chunkserver间比较数据来检测 数据损坏是不现实的。另外，有分歧的备份仍然可能是合法的：根据GFS的变更语义， 尤其是前面提到的原子性的record append操作，并不保证所有副本是完全一致的。因此 每个chunkserver必须通过维护一个检验和来独立的验证它自己的拷贝的完整性。

一个chunk被划分为64kb大小的块。每个块有一个相应的32bit的校验和。与其他的元数据 一样，校验和与用户数据分离的，它被存放在内存中，同时通过日志进行持久化存储。

对于读操作，chunkserver在向请求者(可能是一个client或者其他的chunkserver)返回数据 前，需要检验与读取边界重叠的那些数据库的校验和。因此chunkserver不会将损坏数据 传播到其他机器上去。如果一个块的校验和与记录中的不一致，chunkserver会向请求者 返回一个错误，同时向master报告这个不匹配。之后，请求者会向其他副本读取数据，而 master则会用其他副本来clone这个chunk。当这个合法的新副本创建成功后，master向报告 不匹配的那个chunkserver发送指令删除它的副本。

校验和对于读性能的影响很小，因为：我们大部分的读操作至少跨越多个块，我们只需要 读取相对少的额外数据来进行验证。GFS client代码通过尽量在校验边界上对齐读操作 大大降低了开销。另外在chunkserver上校验和的查找和比较不需要任何的IO操作， 校验和的计算也可以与IO操作重叠进行。

校验和计算对于append文件末尾的写操作进行了特别的优化。因为它们在工作负载中占据了 统治地位。我们仅仅增量性的更新最后一个校验块的校验值，同时为那些append尾部的 全新的校验块计算它的校验值。即使最后一个部分的校验块已经损坏，而我们现在无法 检测出它，那么新计算出来的校验和将不会与存储数据匹配，那么当这个块下次被读取时， 就可以检测到这个损坏。(也就是说这里并没有验证最后一个块的校验值，而只是更新它的 值，也就是说这里省去了验证的过程，举个例子假设最后一个校验块出现了错误，由于 我们的校验值计算时是增量性的，也就是说下次计算不会重新计算已存在的这部分数据的 校验和，这样该损坏就继续保留在校验和里，关键是因为这里采用了增量型的校验和计算 方式)

与之相对的，如果一个写操作者覆盖了一个现有chunk的边界，我们必须首先读取和验证 操作边界上的第一个和最后一个块，然后执行写操作，最后计算和记录新的校验和。如果 在覆盖它们之前不验证第一个和最后一个块，新的校验和就可能隐藏掉那些未被覆盖的 区域的数据损坏。(因为这里没有采用增量计算方式，因为它是覆盖不是append所以现有的 检验和就是整个块的没法从中取出部分数据的校验和，必须重新计算)。

在空闲期间，chunkserver可以扫描验证处在非活动状态的trunk的内容。这允许我们检测到 那些很少被读取的数据的损失。一旦损坏被发现，master就可以创建一个新的未损坏副本 并且删除损坏的副本。这就避免了一个不活跃的坏块骗过master，让之以为块有足够的 好的副本。

全面而详细的诊断性的日志以很小的成本，带来了在问题分解，调试，性能分析上不可 估量的帮助。没有日志，就很难理解那些机器间偶然出现的不可重复的交互。GFS生成一个 诊断日志用来记录很多重要事件(比如chunkserver的启动停止)以及所有RPC请求和应答。 这些诊断日志可以自由的删除而不影响系统的正常运行。然而，只要磁盘空间允许，我们 会尽量保存这些日志。

RPC日志包含了所有的请求和响应信息，除了读写的文件数据。通过匹配请求和响应，整理 不同机器上的RPC日志，我们可以重新构建出整个交互历史来诊断一个问题。这些日志也 可以用来进行负载测试和性能分析。

因为日志是顺序异步写的，因此写日志对于性能的影响是很小的，得到的好处却是大大的。 最近的事件也会保存在内存中，可以用于持续的在线监控。

我们在一个由一个master，两个master备份，16个chunkserver，16个client组成的GFS集群 上进行了性能测量。这个配置是为了方便测试，实际中的集群通常会有数百个 chunkserver，数百个client。

所有机器的配置是，双核PIII 1.4GHz处理器，2GB内存，两个80G，5400rpm硬盘，以及 100Mbps全双工以太网连接到HP2524交换机。所有19个GFS服务器连接在一个交换机，所有 16个客户端连接在另一个上。两个交换机用1Gbps的线路连接。

我们选择在google内部使用的两个集群进行测试作为相似的那些集群的一个代表。集群A 主要用于100多个工程的日常研发。它会从数TB的数据中读取数MB的数据，对这些数据进行 转化或者分析，然后将结果再写回集群。集群B主要用于产品数据处理。它上面的任务持续 时间更长，持续地在生成和处理数TB的数据集合，只是偶尔可能需要人为的参与。在这两种 情况下，任务都是由分布在多个机器上的很进程组成，它们并行的读写很多文件。

在这一节，我们将继续在两个新的集群上对工作负载进行细致的对比分析。集群X是用于 研究开发的，集群Y是用于产品数据处理。