Google File System

Google File System

GFS设计思想

​ GFS的设计目标是设计一个可伸缩、高可用、高可靠的分布式文件系统，为了达到这一设计目标，其设计思想包含以下内容：

• 为控制成本该系统是构建在成百上千台普通、廉价的设备组装成的存储集群，同时要被相当数量的客户机访问。因此组件失效被视作是常态而不是意外事件，即任何时间都可能有某些组件无法工作或无法从目前的失效状态中恢复。
• 该系统存储的文件可能非常巨大（GB级的文件非常普遍），每个文件又通常都包含许多应用程序对象，所以经常需要处理由数亿个对象构成且快速增长的、TB级的数据集。
• 该系统的读写操作简单可靠，绝大部分的修改是在文件尾部顺序追加写入，而不是覆盖原有数据写入。一旦写入，对文件的操作就只能读取，而且通常是按顺序读取，同时支持小规模的随机读取。
• 系统放宽对一致性模型的要求，引入原子性的记录追加操作，从而保证大量客户端并发的进行追加操作时，不需要额外的同步操作，以保证写入的高效性和数据的一致性。

GFS体系架构

​ GFS系统由三部分组成：GFS master、GFS client、GFS chunkserver架构图如下所示：

​ GFS client是给应用使用的API，这些API接口与POSIX API类似，代码以库的形式被链接到客户程序里。应用程序同时与Master节点和Chunk服务器通信，对数据进行读写操作，一方面GFS client和GFS master的通信是为了获取元数据等控制信息*(Control message)，另一方面GFS client和GFS chunkserver直接交互进行数据操作获取数据信息(Data message)*。

​ GFS chunkserver是chunk服务器把chunk块c以linux文件的形式保存在本地硬盘上，根据指定的chunk标识和字节范围来读写块数据，为保证可靠性每个chunk块会复制到多个chunkserver上。

​ GFS master是系统的元数据服务器，维护的元数据包括：文件和chunk的命名空间namespace（GFS中文件以分层目录的形式组织，用路径名来标识，在逻辑上，GFS的命名空间就是一个全路径和元数据映射关系的查找表）、文件和chunk的对应关系，chunk副本的位置信息。其中，前两者是会持久化的，而chunk的位置信息来自于chunkserver的汇报，即master不会持久保存chunk位置信息，因为在一个有成百上千台服务器的集群中，诸如有chunk服务器加入或离开集群、更名、失效、重启等事件会频繁发生，所以采用master在启动及以后定期轮询chunk服务器及其更新的设计来简化master和chunk服务器数据同步的问题。即在master启动或者有新的chunk服务器加入时，master向各个chunk服务器轮询它们所存储的chunk信息，并通过周期性的心跳信息监控chunk服务器的状态。

​ GFS master通过操作日志来持久化保存文件和chunk的命名空间、文件和chunk的对应关系这两种类型的元数据。这两种元数据都以操作日志的方式记录在操作系统的系统日志文件中，同时元数据变更形成的操作日志不但可以作为元数据唯一的持久化存储记录，也可以作为判断同步操作顺序的逻辑时间基线。本地master记录上述两种元数据的日志也会被复制到其它的远程master服务器上，这样可以提高系统的可靠性，系统能简单可靠的更新master服务器的状态，不用担心master服务器崩溃导致数据不一致的风险。

​ GFS master崩溃时通过两种方式进行系统恢复，一种是本地master自恢复，另一种则是master切换。master自恢复是通过重演操作日志把文件系统恢复到最近的状态，这种方式存在一个显著的问题，那就是长时间运行的master服务器日志过长，GFS通过使用checkpoint来减少重演操作的日志量。当日志增长到一定量时，master对系统状态进行一次checkpoint，将所有的状态数据写入一个checkpoint文件，并删除之前的日志文件，值得一提的是这个过程不会阻塞master中正在进行的修改操作，因为master使用独立的线程切换到新的日志文件与创建新的checkpoint文件。当master服务器需要进行系统恢复时，从磁盘上读取最新的checkpoint文件，重演checkpoint之后的有限个日志文件完成回退恢复。

​ 当处于GFS系统外部的监控进程发现GFS master进程所在的机器宕机或磁盘失效，则采用master切换的机制进行系统恢复，即监控进程在其它的存有完整操作日志的机器上启动新的master进程，通过更改客户端用于访问master节点的类似DNS别名的规范名字的实际指向，让客户端访问新的master节点。这一过程的实现有赖于master状态复制机制，为保证master服务器的可靠性，master的状态（所有的操作日志和checkpoint文件）会被复制到多台机器上，这样就形成了针对“主”master服务器的多个**“影子”master节点**，它们在“主”服务器宕机时提供文件系统的只读访问。“影子”master为保持自身状态是最新的，通过读取当前正在进行的操作日志副本，并依照和主master相同的顺序来更改内部的数据。

GFS数据访问

​ 为了简化系统设计，GFS采用单一master节点的策略，这种策略也带了问题，其中一个就是master节点可能成为整个系统性能的瓶颈，为了避免这一问题GFS数据访问的关键在于减少对master节点的读写操作。具体措施为：client不通过master节点读写文件数据，仅向master节点询问它应该联系的chunk服务器；client和master服务器都将这些元数据信息缓存一段时间；后续的数据读写操作client直接与chunk服务器交互。另外，chunk服务器中的chunk块大小也直接影响着master节点的读写操作频率，采用较大的chunk块尺寸可以减少了client和master节点通讯的需求，因为应用程序通常连续地读写大文件，客户端可以轻松缓存一个数TB级的工作数据集对应的chunk位置信息。

​ 所以GFS中chunk块采用惰性分配策略：每个Chunk（副本）都以普通Linux文件的形式保存在Chunk服务器上，只在需要的时候才扩大。这种分配策略不仅避免了因内部碎片造成的空间浪费，还可以减少Master节点需要保存的元数据数量有利于元数据全部放在内存中提高master性能，同时减少了client与master的通信需求，增大了client与chunkserver保持较长时间TCP连接的概率能够减少网络负载。但这种分配策略也带来了许多缺陷，其中一个就是 小文件包含较少的Chunk(甚至只有一个Chunk)，当有许多的客户端对同一个小文件进行多次的访问时，存储这些Chunk的Chunk服务器就会变成热点。

GFS读取数据流程

​ 在体系架构中介绍的GFS架构体现的就是一个数据读取过程，如下图所示：

​ 具体步骤如下：

1. client上的application调用GFS client提供的接口，表明要读取的文件名、偏移、长度。
2. client将文件名和应用程序指定的字节偏移根据固定的chunk大小转换成文件的chunk索引，进而把文件名和chunk索引发送给master节点。
3. master节点将相应的chunk标识和副本的位置信息发告诉client。
4. client用文件名和chunk索引作为key本地缓存这些信息，之后一般情况下client选择最近的一个chunkserver副本发送请求，请求中包含chunk标识和字节范围。
5. chunkserver读取相应chunk数据，并将数据返回给client

​ 读取数据过程中值得一提的是，client访问master节点并开始了对chunk的数据读取操作后，client不必再和master节点通信，除非缓存的元数据信息过期或者文件被重新打开。因为在实际过程中，client通常会在一次请求中查询多个chunk信息，即client的一次master节点访问中，master节点的回应可能包含了被请求chunk的后续chunk信息，这样可以用同样代价的额外元数据，避免客户端和master节点未来可能会发生的多次通信。

GFS写入数据流程

​ client和master的通信仅限于获取目标chunk副本的位置，为了减少master负担，GFS系统采用了元数据缓存机制，client在获得并缓存副本位置后就不再和master交互。GFS系统在并发情况下可能存在多个应用程序同时修改同一个chunk，为了使多个副本之间修改保持一致，需要为修改操作定义统一的时序。GFS系统这种并发写入情况下，采用的元数据缓存机制使得无法使用master来定义修改操作的统一时序，为此提出了租约(lease)机制来代替master完成这一任务。具体来说，master节点通过建立租约，并将其授权给某个chunk副本Replica，称其为Primary，后续由它来确定数据修改的一个执行顺序，其它chunk副本照做，租约机制实现的GFS写入数据流程如下图所示：

​ 具体步骤如下：

1. client向master节点询问持有当前租约的chunk（Primary），以及其它副本（Replica）的位置，如果没有chunk持有租约，master就随机选择其中一个副本建立一个租约。
2. master将Primary的标识符以及其它副本（secondary replica）的位置返回给client。此后只有在当前Primary不可用或向client表明它已不再持有租约时，client才重新联系master节点。
3. client把要写入的数据按任意顺序推送到所有的副本上。chunk服务器把接收到数据保存在内部LRU缓存中，直到数据被使用或过期交换出去。
4. 当所有的副本都确认收到了数据后，client向Primary发送写入请求。Primary为接收到的所有操作分配连续的序列号（这些操作可能来自不同的客户机，序列号保证了操作顺序执行），按序列号的顺序把操作应用到primary自己的本地状态中。
5. Primary把写入请求传递到所有的二级副本（Secondary Replica），每个二级副本按照Primary分配的序列号以相同的顺序执行这些操作。
6. 所有的二级副本向Primary确认已经完成所有操作。
7. Primary回复client写入操作执行情况。当写入操作执行出错时，Primary会将任何副本产生的任何错误都返回给client。出现错误的情况下，写入操作可能在主Chunk和一些二级副本执行成功，但是client写入请求会被确认为失败，这时被修改的region处于不一致状态，client会重复执行步骤3-7，兜底措施是从头开始重新执行1-7。

​ 值得注意的是，这个流程特意将数据流与控制流分开：client先向 Chunk Server 提交数据，再将写请求发往 Primary。这么做的好处在于 GFS 能够更好地利用网络带宽资源。从上述步骤可见，控制流借由写请求从client流向 Primary，再流向其他 Secondary Replica。实际上，数据流以一条线性数据管道进行传递的：client会把数据上传到离自己最近的 Replica，该 Replica 在接收到数据后再转发给离自己最近的另一个 Replica，如此递归直到所有 Replica 都能接收到数据，如此一来便能够利用上每台机器的所有出口带宽。

GFS记录追加

​ 除了数据写入操作，GFS系统还提供了特殊的修改操作，一种原子性的数据追加操作，除了在Primary有些额外的控制逻辑，遵循一般的写入操作控制流程：

1. client把数据推送给文件最后一个chunk的所有副本Replica，然后发送请求给Primary。
2. Primary检查这次记录追加操作是否会使Chunk超过最大尺寸。如果超过，则Primary先将当前chunk填充到最大尺寸，之后通知所有二级副本（Secondary Replica）做同样的操作，然后回复client通知其对下一个chunk重新进行记录追加操作。如果数据能够被放入到当前块中，那么 Primary 会把数据追加到自己的 Replica 中，获得追加成功返回的偏移值，然后通知其他 Replica 将数据写入到该偏移位置中。
3. Primary向client确认记录追加操作结果。

​ 至少一次追加at least once是GFS系统中记录追加操作的设计思想，如果记录追加操作执行失败，Primary会将任何副本产生的任何错误都返回给client，它便会重试追加操作。和写入操作的情形相同，一个chunk的不同副本可能重复包含一个记录全部或者部分的数据，前面追加操作执行失败的副本只写入了部分数据，而执行成功成功的副本已经顺利写入了这些数据，重新进行数据追加便会导致这些副本上出现重复数据，不过 GFS并不保证Chunk的所有副本在字节级别是完全一致的，只保证数据作为一个整体原子的被至少写入一次。如下图所示失败的记录追加操作可能导致chunk间字节级别不一致，但当最终追加成功后，所有副本在返回的偏移位置一致已定义，之后的追加操作不受影响。

​ O_APPEND打开文件是GFS记录追加操作原子性的技术保证，使用O_APPEND选项在linux系统层面声明在文件的末尾写入，即先移动到文件末端再写入数据。例如并发情况下，两个独立的进程T1和T2同时追加数据到一个文件里，用lseek移动文件指针到其他的位置，用write写入数据，某一时刻两进程调用lseek指向同一文件位置，进程T1先调用write执行追加操作，调度到进程T2由于已经调用lseek指定位置这时调用write写入可能导致互相覆盖。使用O_APPEND打开文件每次标志位都移动到文件的末端，这样避免了记录追加过程中的数据覆盖，很明显可以看出O_APPEND提供了无锁的文件追加方式。

GFS快照机制

​ GFS系统还提供了文件快照操作，可以对一个文件或目录树做一个拷贝，这一过程几乎是瞬间完成，几乎不会对正在进行的其它操作造成任何干扰。用户可使用快照操作迅速创建一个巨大数据集的分支拷贝，或使用快照操作备份当前状态之后可以轻松的提交或回滚到备份时的状态。

​ 快照操作的实现采用了写时复制（Copy on Write）的技术：

1. master节点收到快照操作请求，首先取消快照操作执行对象中所有文件对应chunk的租约（lease），因为后续对这些chunk的写操作都必须与master交互以找到租约持有者Primary的位置，从而给master一个率先创建chunk新拷贝的机会。
2. 租约取消或过期之后，master把操作以日志的方式记录到硬盘上，然后通过复制源文件或目录元数据的方式，把日志记录的变化反映到内存的状态中。复制操作中新创建的快照文件和源文件指向完全相同的chunk地址，chunk引用计数变为1。
3. 快照操作后，当有client尝试对这些chunk进行写入时，client先发送请求到master查询当前的租约持有者Primary；master会注意到经过快照操作的chunk的引用计数大于1，此时，master 会为即将产生的新chunk生成一个句柄Handle；然后master通知所有持有经过快照操作的chunk的chunk服务器在本地创建出一个新的chunk；最后，master节点确保新chunk的一个副本拥有租约并回复client，client得到回复后就可以正常的写入数据到新的chunk。

GFS一致性保障机制

​ GFS提供的一致性保障机制称之为“relaxed consistency”，relaxed是指，系统在某些情况下是不保证一致性的，例如，Dirty Read情况读取到尚未完全写完的数据；数据过程读取过程中的填充数据（padding）和重复内容；数据修改追加不一致等情况。在这些异常情况下，GFS是不保证一致性的，需要应用程序来处理。

​ 在读取数据时，为了避免读入填充数据或是损坏的数据，数据在写入前往往会放入一些如校验和等元信息以用于验证其可用性，如此一来 GFS 的 client library 便可以在读取时自动跳过填充和损坏的数据。不过，鉴于数据追加操作的 at lease once 特性，client仍有可能读入重复的数据，此时只能由上层应用通过鉴别记录的唯一ID等信息来过滤重复数据了。

​ GFS 支持的指定偏移值数据写入（Write）和数据追加（Record Append）两种文件数据修改方式中也有一致性保障机制。当写入时，指定的数据会被直接写入到client指定的偏移位置中，覆盖原有的数据。GFS 并未为该操作提供太多的一致性保证：如果不同的client并发地写入同一块文件区域，操作完成后这块区域的数据可能由各次写入的数据碎片所组成，即进入不确定的状态。与写入操作不同，GFS 确保即便是在并发时，数据追加操作也是原子且 at least once（至少一次）的。操作完成后，GFS 会把实际写入的偏移值返回给客户端，该偏移值即代表包含所写入数据的确定的文件区域的起始位置。由于数据追加操作是 at least once 的，GFS 有可能会在文件中写入填充（padding）或是重复数据，但出现的概率不高。

文件region的checksum与重复内容

​ 有效性校验checksum GFS系统在执行写入操作时，每条写入的记录中都包含了额外的信息，其中就有用来验证写入内容有效性的checksum。当系统执行读取操作时，可以利用记录中的checksum来识别、抛弃偶然性的填充数据和重复内容。另外，系统运行时可能存在组件失效导致损坏或者删除数据，这种数据损坏情况下，也可以使用checksum对其进行有效性校验，一旦发现数据损坏问题，就尽快利用有效的副本恢复数据，只有当一个chunk的所有副本被检测到了错误并在采取应对措施之前全部丢失，这时该chunk的数据丢失才是不可逆转的。

​ 记录的唯一标识符是用来过滤文件region中的重复数据的重要方法，它通常用于命名程序中处理的实体对象。前面已经提到GFS系统中的记录追加操作是至少一次追加的，所以client在读取数据时就有可能读取到重复的数据，此时只能由上层应用通过鉴别记录的唯一标识符等信息来过滤重复数据。

文件region一致性模型（File Region State After Mutation）

​ 文件命名空间完全由单节点 Master 管理在其内存中，这部分数据的修改可以通过让 Master 为其添加互斥命名空间锁来解决并发修改的问题，因此命名空间的数据修改是可以确保原子性和正确性。

​ 但是文件的数据修改则相对复杂，当文件region被修改后，它可能进入以下三种状态的其中之一：

• 一致的Consistent所有client无论从哪个副本读取，读到的数据都一样，那么认为文件region是一致的
• 已经定义的Defined对文件的数据修改之后，region是一致的，并且client能够看到写入操作全部的内容，那么这个region是已定义的
• 不一致的Inconsistentclient读取不同的 Replica 时可能会读取到不同的内容，那这个region是不一致的

​ 文件region修改后所处状态如下图所示，数据修改成功执行，且没有受到同时执行的其它写操作的干扰，则影响的region就是已定义的（隐含了一致性）。并行修改操作成功完成之后，region处于一致的、未定义的状态，即所有的client看到同样的数据，但可能无法读取到写入的全部数据。写入操作执行失败则会让region进入不一致状态。

操作顺序与版本检测

​ 经过了一系列成功的修改操作之后，GFS确保被修改的文件region是已定义的，并且包含最后一次修改操作写入的数据。GFS系统提供了两种措施确保被修改的文件region是已定义的，一种是保证系统对chunk所有副本的修改操作顺序一致；另一种是版本检测，使用chunk版本号来检测副本是否因为它所在的chunk服务器宕机而错过了修改操作导致其失效。如果副本失效，master节点不会将失效副本的位置信息返回给client，该副本也将不会再进行任何修改操作而是等待垃圾收集系统尽快回收。

​ 操作顺序一致GFS系统是通过租约机制来实现的，由Primary来确定数据修改的执行顺序，其他所有副本照做。

​ 版本检测则是通过对chunk版本号的时效性检测来检测失效副本，chunk版本变更是由于master与chunk签订新租约时，master会增加chunk的版本号，然后通知最新的副本。如果某个副本所在的chunk服务器处于失效状态，会出现chunk版本变更异常情况该副本版本号不会增加，当该chunk服务器重新启动并向master报告其拥有的chunk集合及版本号时，master可检测出这些过期的chunk。因为在client对新版本chunk执行修改操作之前，master和chunk副本都已经通过操作日志的方式把新版本号记录在它们持久化存储的状态信息中，所以如果master在检测过期chunk时，看到一个比某个chunk记录的版本号更高的版本号，master会认为它和chunk服务器签订租约的操作失败了，此时会选择更高的版本号作为当前版本号。

​ chunk时效检测，首先，master通知版本号在master通知client某个chunk服务器持有租约、或者向其指定chunk服务器进行克隆时，消息中都附带了chunk的版本号；然后，版本号验证，过期不回复如果某个chunk副本因错失一些修改操作而过期失效，master节点不会将失效副本的位置信息返回给client，该副本也不会再进行任何修改操作而是等待master垃圾收集系统尽快回收。

GFS空间管理

GFS锁机制

​ 为了管理来自不同client的并发请求对 GFS系统namespace 的修改，master会为 namespace 中的每个文件和目录都分配读锁和读写锁。读写锁支持对同一目录的并行操作，可以在同一个目录下同时创建多个文件，其中每一个操作都会获取一个目录名的上的读锁和文件名上的写入锁。目录名的读锁可以防止目录被删除、改名以及被快照，文件名的写入锁确保在串行化文件创建操作中不会多次创建同名的文件。由此，对不同 namespace 区域的并发请求便可以同时进行。

​ 所以，一般情况下，master节点的每个操作在开始之前都要获得一系列的锁，例如，一个写入操作涉及某个路径/d1/d2/…/dn/leaf其中leaf可以是一个文件，也可以是一个目录，那么在写入操作执行之前它首先要获得目录/d1，/d1/d2到/d1/d2/…/dn所有目录层的读锁，以及/d1/d2/…/dn/leaf的读写锁。因为namespace可能有很多节点，大量的读写锁可能会造成较高的内存占用，所以读写锁分配采用惰性分配策略，它们在实际需要时才进行创建，并且在不再使用时立刻删除。此外，锁的获取依据一个全局一致的顺序，首先按namespace树的层次排序，在同一个层次内按字典顺序排序，通过这种顺序封锁法来避免死锁。

副本管理

​ 为了进一步优化 GFS 集群的效率，master在副本（Replica）的位置选取上会采取一定的策略。master 的副本编排策略主要为了实现两个目标：最大化数据的可用性，以及最大化网络带宽的利用率。为此，副本不仅需要被保存在不同的机器上，还会需要被保存在不同的机架上，这样如果整个机架不可用了，数据仍然得以存活。如此一来，不同client对同一个chunk进行读取时便可以利用上不同机架的出口带宽，但坏处就是进行写入时数据也会需要在不同机架间流转。

​ 副本的生命周期转换操作实际只有两个：创建和删除。首先，副本的创建可能源于以下三种事件：chunk的创建、副本复制、以及副本移动。

​ chunk的创建chunk在系统执行写入操作写入数据时才被物理上创建，master创建一个chunk是，需要选择在哪里放置初始的空副本，考虑以下几个因素：

1. 尽量选择低于平均硬盘使用率的chunk服务器
2. 限制每个chunk服务器上近期chunk创建操作的次数，虽然chunk在写入操作真正执行写入数据时才被创建，但是创建也意味着随之会有大量的写入数据的操作，这将带来巨大的写入操作压力
3. 尽量把Chunk的副本分布在多个机架之间

​ 副本复制当chunk的某些副本数据损坏了，或者chunk副本的复制因数提高了，就出现了chunk的有效副本数量可能少于用户指定复制因数的情况，这时master会重新复制chunk。当有多个需要被重新复制的chunk时，master会根据几个因素进行排序：

1. chunk现有副本数量和复制因数相差的数量，丢失较多副本的chunk优先级更高
2. 优先复制活跃文件的chunk而不是最近刚被删除文件的chunk
3. 提高会阻塞客户机程序处理流程的chunk的复制优先级

​ 有了chunk的优先级后，master会选取当前拥有最高优先级的chunk，然后命令某个chunk服务器直接从可用的副本克隆一个副本出来。选择新副本位置的策略和chunk创建过程类似：平衡硬盘使用率、限制同一台Chunk服务器上的正在进行的克隆操作的数量、在机架间分布副本。另外，为防止克隆产生的网络流量太大而超过client的流量，一方面，master会限制整个集群和每个chunk服务器上的同时进行的克隆操作的数量；另一方面，chunk服务器通过调节它对源chunk服务器读请求的频率来限制它用于克隆操作的带宽。

​ 副本移动 master会周期性地对副本进行负载均衡，先检查当前副本分布情况，然后移动副本以更好的利用硬盘空间、更有效的进行负载均衡。master选择被移动副本的因素有：

1. 通常移走剩余空间低于平均值的chunk服务器上的副本，从而平衡系统整体的硬盘使用率
2. master逐渐地填满一个新的chunk服务器，而不是在短时间内用新chunk填满它，以至于过载

垃圾回收

​ GFS系统采用惰性策略进行垃圾回收，GFS文件删除后不会立刻回收其物理空间，而是采用惰性回收策略，只在文件和chunk级的常规垃圾收集时进行。

​ 首先，采用日志和隐藏的方式删除文件，当文件被应用程序删除时，master立刻把删除操作以日志的方式记录下来。但是，master并不马上回收资源，而是把文件名改为一个包含删除时间戳的、隐藏的名字。

​ 然后，进行命名空间定期回收，master会对文件系统命名空间namespace做常规扫描，此时它会删除所有指定时间间隔外的隐藏文件，这时候master才会真正地将该文件从namespace中移除。文件被真正删除前，它们仍旧可以用新的特殊名字读取，也可通过把隐藏文件改名为正常显示文件名的方式撤销删除操作。

​ 接着，使用孤立的方式切断文件与其相关chunk的连接，当隐藏文件被从命名空间中删除，master内存中保存的这个文件的相关元数据才会被删除，这就有效的切断了文件和它包含的所有chunk的连接。

​ 之后，删除孤儿chunk，master会对chunk命名空间做类似的常规回收扫描，此时会找到不与任何文件连接的孤儿chunk，并删除它们的元数据。

​ 最后，删除孤儿chunk的副本 ，chunk服务器在与master交互的心跳信息中，报告它拥有的chunk子集信息，master节点回复这其中哪些chunk在master节点保存的元数据中已不存在，此时，chunk服务器可以任意删除这些无用chunk的副本。

采用这种删除机制主要有如下三点好处：

1. 对于大规模的分布式系统来说，这样的机制更为可靠：在chunk创建时，创建操作可能在某些 chunk服务器上成功了，在另一些chunk服务器上失败了，这导致后者上可能存在master不知道的chunk副本。除此以外，删除chunk副本的请求可能会发送失败，master需要记得尝试重发。相比之下，由chunk服务器主动地删除chunk副本能够以一种更为统一的方式解决这种问题。
2. 这样的删除机制将存储回收过程与master日常的周期扫描过程合并在了一起，这就使得这些操作可以进行批处理，以减少资源损耗。

References

Google File System

Google File System 总结