The Google File System 论文解读

The Google File System 论文解读

• • 1. 前言
  • 2. 架构
  • • 2.1 架构设计

• 3. Data segment

• • 3.1 数据段的大小及数量设置

  • 3.2 副本的存放位置及安置方式

  • 3.3 数据段的容错复制机制及负载均衡策略

  • 3.4 租赁(lease)

    • 4. master

    • • 4.1 元数据
      • 4.2 chunk 管理
      • 4.3 操作日志 log
      • 4.4 快照 snapshoot
      • 4.5 命名空间锁

    • 5. Client

    • 6. 系统交互

    • • 6.1 读
      • 6.2 写
      • 6.3 追加

    • 7. 一致性模型

    • • 7.1 读、写、追加的一致性
• 8. 垃圾收集
• 9. 容错机制及诊断流程

• 9.1 过期失效文件的检测机制

• 9.2 快速恢复策略

• 9.3 chunk复制操作方案

• 9.4 master数据的复制操作

• 9.5 数据完整性保障措施

• 9.6 诊断工具应用指南

  • 10. GFS 的优点
  • 11. GFS 的缺点

1. 前言

Google File System（GFS）是 Google 设计实现的一个分布式文件系统。它是一个针对大规模数据密集型应用场景设计的分布式文件系统。该系统具备良好的性能保障、良好的扩展能力和较高的可靠性及可用性。它不仅继承了传统分布式文件系统的优点，并且基于自身应用程序和技术环境进行特殊化设计。具体采用以下策略：对存储管理方案进行了优化；对资源调度机制进行了创新设计；对网络协议进行了改进；对容灾备份能力进行了强化；并对能耗控制措施进行了优化；并对日志管理和监控功能进行了完善等各项核心功能进行优化与改进。

• 由于 GFS（基于服务架构）系统采用的服务计算模型具有较强的扩展性特点, 在这种架构下, 组件失效被视为一种常见现象, 因此需要通过持续监控机制实现对该类事件的有效捕捉与快速响应, 同时还需要建立完善的错误检测、灾难冗余以及自动恢复机制, 这些功能模块均需集成到该系统中。
• 数据量的增长要求我们既要确保小文件的处理效率, 又要实现对大文件的有效管理与优化。
• 系统主要针对那些仅需在文件尾部追加数据而不进行覆盖原有数据操作的应用场景进行设计, 其他如生产者-消费者队列等场景也属于该系统的适用范围。
• 系统采用了较弱的一致性要求, 并通过原子性的记录追加操作来保证多个客户端可同时完成追加操作而不影响整体一致性。
• 目标程序对于大规模的数据处理有较高的需求, 尤其强调的是稳定带宽的重要性, 而不是追求低延迟响应时间。
• 该系统支持两种常见的读取方式: 大规模的数据流读取和小规模的随机读取。
  • 大规模的数据流读取通常用于1MB以上的数据处理, 应用程序通过连续区域读取的方式来实现, 这种方式一般是在尾部附加数据
  • 小规模的随机读取通常用于少量的数据获取(几个KB), 这种情况下并不需要非常高效的读取方式
  • 当一旦写入后, 数据修改的机会非常少

2. 架构

基于分布式存储框架设计的思想 GFS 模拟传统系统功能的一组API接口函数 ，不遵循POSIX标准 ，其采用层次化的目录结构进行管理 ，所有资源均通过路径名进行标识 。该存储方案支持包括创建新资源 读取与写入现有资源 复制现有目录及其子目录等基本操作 ，并特别引入了快照操作 （一种低成本复制现有目录及其子目录副本的方式 ）以及记录追加操作 （允许多个客户端同时向同一资源进行数据追加操作 ），其中记录追加操作至少保证有一次有效的成功记录 。

2.1 架构设计

一个 GFS 集群包含：一个 master 、多台 chunkserver 、同时被多个 client 访问

将每个文件划分为多个 chunk ，每个 chunk 的容量设置为 64MB 。为了确保数据存储的可靠性，在每一个 chunk 中存储三份备份，并将这些备份分别存放于三个不同的机架中的特定 chunkserver 系统中。

在 master 上存储元信息：包含命名空间、访问控制信息以及文件与 chunks 的映射关系和 chunks 的位置分布； master 会与 chunk server 进行心跳通信以实现实时状态同步。

client和chunkserver都不缓存 文件数据，易造成缓存一致性问题

控制与数据信息分离 * 用户与主节点交互以执行元数据操作

• 用户代理直接连接至片段服务器以统一处理文件相关操作
• 这意味着通过根据网络拓扑优化数据流调度可以提高系统性能
• 此外该方法允许实现资源分配与任务分配上的效率提升

3. Chunk

3.1 chunk 大小与数量

• 该 chunk 的容量设定为 64MB，并被指定一个唯一且固定不变的 chunk handle 来标识。基于 chunk handle 和指定的字节范围 range 可实现对 chunk 的读写操作。

  • 每个 chunk 副本均按照标准 Linux 文件格式存储于 chunkserver 服务器上，并采用惰性资源分配策略以避免由于内部碎片化而导致的空间浪费问题（注：此处对惯性分配策略的相关解释已省略）。
  • 在 master 节点中使用小于 64 字节的元数据字段来记录此块数据，并包含以下信息：
    • 当前副本的位置信息以及引用计数字段用于实现复制功能
    • 版本字段用于标识数据副本的新旧状态

• 考虑到可靠性要求，在系统设计中采取冗余策略是必要的做法。

• 所有这些副本会被分散部署在多个机架上，并行复制份数设置为3份。

• 选择较大的chunk尺寸具有显著的优势：

  • 减少了客户端与master节点之间的通信开销
  • 通过使用较大的chunk尺寸，在每次请求处理时就能完成更多的数据传输操作
  • 这种设计使得系统能够实现持续稳定的网络连接状态，并降低了整体带宽消耗
  • 同时也减少了master节点需要维护的元数据信息量

• 缺点：

• 由于存储碎片化导致空间浪费

• 小文件通常被划分为若干数据块

• 当同时从多个并发客户端获取大量流量时可能导致系统失控

• 通过提高副本系数能够有效缓解这一问题

3.2 副本的位置 与 放置

• GFS集群采用广泛分布式的多层次架构设计。其存储资源分散部署于多个机架中，在提升系统扩展性的同时实现了更好的资源利用率。

• 通过优化设计，在确保系统高可用性的前提下实现了对硬件组件损伤风险的有效规避。无论是硬盘损坏还是电源供应中断等常见问题都能得到及时有效的防护。

• 系统采用分布式计算框架以最大限度地发挥硬件资源潜力。通过优化任务调度算法使得计算资源得到更充分地利用从而显著提升了系统的吞吐量和处理效率。

• master 创建一个 chunk 时，会选择将初始空副本放置在哪个位置，并主要会考虑以下几点：

• 希望将新副本存储在平均硬盘使用率较低的 chunkserver 上

• 希望限制每个 chunkserver 上最近 生成 chunk 的操作次数

• 希望将 chunk 分散到多个机架上以提高稳定性

• 核心职责是赋予master确定系统状态的能力

• 重要： chunk servers 对其磁盘上的块拥有最终控制权

3.3 chunk 容错复制 和 负载均衡

当 Chunk 的有效副本数量低于用户设定的复制阈值、出现副本损坏状况或 ChunkServer 无法正常运行时,Master 会发起重新复制操作,并指示 ChunkServer 直接从可用的副本中生成一个新的副本.这个新副本的位置选择将与原创建策略保持一致.

优先级因素 ：

• 更倾向于选择副本数量与复制因子差异较大的文件 * 偏好处理当前活跃度较高的文档而非那些刚刚被删除的内容 * 避免影响客户端程序的数据块传输

Master服务器定期执行重排以优化副本分布。该系统会评估当前的副本分布状态，并通过调整位置来最大化硬盘利用率以及提升负载均衡效率。
当新增一个ChunkServer时, Master服务器将采用逐步重排的方式填充该新设备,并避免在短期内过度填充以防止潜在的过载。

3.4 租赁(lease)

设置 primary 的 目的 ：为了最小化 master 的管理负担 。

该系统角色 master 将充当 chunk 的一个副本角色，并授予该副本一个 lease 权限；随后将其命名为 primary（作为主 chunk），其余副本则被指定为 secondary。

primary 对 chunk 的所有更改操作进行记录并存储 ，所有副本都按照该序列执行修改操作 。这样做的原因在于 ，修改操作全局的顺序主要取决于 master 节点选择的 lease 顺序 ，而后由 primary 节点分配的序列号进一步确定

当chunk发生更改时,primary将能够提出租期延长的请求，并经master核实后获得租期延长的时间。这些请求及批准信息通常通过位于master与chunkserver之间的_HeatBeat_进行传递

当chunk发生更改时,primary将能够提出租期延长的请求,and master will verify the request and grant the extended tenancy period. The requests and approval information are typically transmitted through the HeatBeat located between master and chunkserver.

split-brain

4. master

负责全系统的所有活动：管理大块租赁、回收存储空间、负载平衡

4.1 元数据

master 主要存放 3 类型的 元数据 ：

• 文件以及 chunk 这两个命名空间

• 主节点没有采用类似于目录的组织架构

• 每个文件以及每个目录都被定义为查找表中的一个节点，在此过程中实现了对名称与元数据之间的映射关系

• 通过前缀编码实现高效的存储策略（每个命名空间条目占用的空间小于64字节）

• 存在相应的读取与写入锁定机制并将其记录在日志中

• 文件实体与 chunk 的映射关系记录于日志中

  • 每个 chunk 存储位置不在日志记录范围内

4.2 chunk 管理

当生成阶段时，在Markdown中使用 master 对每个 chunk 负责分配一个 unique identifier 作为 chunk handler。

master 会为 chunk 的一个副本建立 lease （租赁）。

在master服务器启动阶段或新加入的chunkserver到来时，该服务器会收集来自各个chunkserver存储的详细信息（包括具体的存储位置等）。通过HeatBeat信息机制，master server会在固定的时间间隔内与所有chunkserver进行通信，并根据接收到的工作状态反馈来执行相应的操作

在定期时间点上，master会对自身存储的元数据执行扫描操作。这种周期性的状态扫描主要应用于以下功能实现：首先，在 chunkserver 失效时进行数据重复制；其次，借助 chunk 的迁移机制来实现跨 chunkserver 的负载均衡；此外还有对磁盘使用状况进行统计等功能。

4.3 操作日志 log

• 操作日志中包含有关键的 元数据变更历史记录 ，在操作日志中，元数据具有...独特的持久化存储特性。
• 操作日志也被用作判断同步操作顺序所需的...逻辑时间基准。
• 会将生成的日志复制到多台远程设备上，并在所有相关日志被成功地写入本地存储以及各远程设备的硬盘驱动器之后才会响应客户端的操作请求。
• 为了尽可能地缩短启动时间，在系统中设置了一个位于主节点上的定期检查机制（即所谓的主定期检查节点），该节点采用类似于B树结构的设计模式，并直接映射至内存空间中。然而，在不延迟接收来自控制台系统的请求输入的情况下立即创建这些检查点（即所谓的逻辑时间基准），从而能够在1分钟内完成包含数百万个文件的集群环境下的构建任务。

4.4 快照 snapshoot

快照复制过程可以在极短时间内生成针对一个 文件或目录树 (源) 的快照副本，并且这种操作基本不影响正在进行中的其他任务。

使用 copy-on-write （ 写时复制 ）技术实现快照 ：

• 当 master 接收到一个 fast snapshot request 时, 首先会释放所有与需要快照文件相关的 chunk lease. 在这些 chunk lease 被取消或失效之后, master 将此次操作记录至日志中, 并通过复制源端的元数据将此日志记录反映至内存中 (此时该 chunk 的引用计数已被增加一,但并未真正复制该 chunk).
• 直到 client 意图将数据写入此处的某个 chunk 时, 才会向 master 发送请求获取 primary key information. master 接收到此请求后会注意到此处的某个 chunk 引用计数已超过一,因此会向所有拥有该 chunk 的副本的 chunkserver 实例中创建拷贝, 并为其中一个新拷贝设置 lease 后返回给 client. client 收到回复后即可正常完成对该 chunk 的修改操作,而原始的那个 copy 则会被保留作为快照.

为了先删除那些需要生成快照的文件块（chunks），因为当 client 和 chunkserver 进行通信时无法确定 primary 节点的情况下，
必须向 master 请求其身份信息，并为此提供了触发条件。

当 master 接收到请求后，
如果该 node 的引用计数大于一，
就会立即启动创建 new chunks 的进程。

最终会将这些 new chunks 分配给相关的 nodes，
并同步到 master 节点上。

选择写时复制的原因是为了减少多余的复制操作。具体来说，在生成快照的过程中，并不是所有的 chunk 都被修改过（与上一次相比），因此只有当某个 chunk 被修改后才真正执行复制操作。

4.5 命名空间锁

为了确保 master 并行操作的正确顺序，请注意所有 master 的操作必须在执行前依次获取一系列锁。

通常情况下，如果一个操作涉及 /d1/d2/…/dn/leaf ，

那么流程首先要获取目录 /d1, /d1/d2, ..., /d1/d2/…/dn 的 read 锁，
此外还需要针对路径 /d1/d2/…/dn/leaf 获取 read-write locks.
根据执行的具体场景, leaf 可以是文件或 directory.

5. Client

GFS 客户端代码被集成到客户程序中作为库使用；该客户端代码负责实现 GFS 系统 API 接口函数、应用程序与 master 和 chunkserver 之间的通信以及对数据的读写操作。

该节点仅获取少量元数据信息，并向主节点查询应联系的CHUNKSERVER集群；客户端会将这些元数据信息进行短暂存储；随后的数据操作会直接与CHUNKSERVER进行交互以完成读写任务。

6. 系统交互

6.1 读

Client传输filename以及基于字节偏移量计算得到的chunk identifier（当前字节偏移量除以64MB）给Master

由 master 返回其相关的位置信息给 client；这些位置信息包括 master 所有副本的位置，并且仅限于最新的 version

由 master 返回其相关的位置信息给 client；这些位置信息包括 master 所有副本的位置，并且仅限于最新的 version

client 以 filename 和 chunk index 为 key缓存这些数据

客户端程序发起请求至 chunk server（通常选择最近的那个），请求内容包括 chunk identifier 和 byte范围。

chunkserver 读取文件，返回数据

该客户接收到了数据，并采用校验码去除了填充数据，在必要时也去除了重复项。

GFS包含处理填充数据及重复数据的功能库。
在程序运行过程中：

1. 应用程序读取每个条目的唯一标识符。
2. 程序对每个独特标识进行比对：
   a. 如果当前记录的独特标识与之前记录的独特标识相同，则跳过该条目。

client 缓存信息到期或文件被重新打开前，client 不必再与 master 通信 。

client 通常会在一次请求中查询多个 chunk 信息 。

上述流程主要用于处理大规模的数据流；如果需要进行小规模随机读取 的操作，则一般情况下会将这些操作整合排序，并进行批量处理。

6.2 写

针对每个Request Block，请重新审查这一逻辑流程是否存在问题。
当存在多个Master-Secondary对时，请确保系统会根据当前时间戳自动选择最新出现的那个Master-Secondary对作为当前MasterNode。
此外，在整个流程运行期间，请持续跟踪并记录每个Master-Secondary对的状态变化情况。

2. master 将 primary 的标识符和 secondary 的位置返回给 client ，client 缓存这些数据后续使用 。只有 primary 不可用或 lease 已到期，client 才会再跟 master 进行联系 。
3. client 将数据推送到所有的副本上（ 数据以管道的方式，顺序沿着一个 chunkserver 链进行传送，优先选择最近的 chunkserver ），chunkserver 接收到数据并保存在 LRU 缓存中。
4. 所有副本确认接收到数据后，client 发送写请求到 primary 。这个请求标识了早前推送到所有副本的数据，primary 为接收到的所有操作分配连续的序列号（ 这些操作可能来自不同的 client ）。primary 以序列号的顺序将操作在本地执行 。
5. primary 将写请求传递到所有的 secondary ，secondary 依照相同的序列号执行操作 。
6. 所有 secondary 回复 primary 已完成操作 。
7. primary 回复 client 。若返回错误，client 重复发起操作请求 。

If an application attempts to write a large amount of data in a single operation or if the data spans across multiple chunks, the client will automatically split these operations into multiple writes.
By separating the data flow and control flow, we can effectively utilize each machine's bandwidth while avoiding network bottlenecks and high-latency connections, thereby reducing the delay caused by propagating all the data.

6.3 追加

GFS支持了原子性的记录追加功能。通过记录追加机制，客户端只需指定需写入的数据块即可；GFS会确保执行至少一次原子操作（即写入一个有序的 byte 流），并将数据追加至 GFS 指定的偏移位置上，并返回指定偏移位置的信息给客户端client。

在传统方式中进行写入操作时,client 必须明确指定数据的偏移位置,当多个 client 同时对同一个 region 进行并行写入时,**region_ 的尾端可能会存储来自不同 client 写入的数据片段.

追加操作流程与写流程（ 本文 6.3 ）基本一致，区别在于：

• 步骤4至6

• 客户端将数据发送至文件最后一位副本所在的 chunk 后，请主节点接收此请求。

• 主节点会判断新增数据大小是否达到上限（64MB）。

• 若超出限制，则主节点将当前 chunk 填充至最大容量，并指示从备份数组中选择下一个副本。

• 最后会返回确认信息给客户端，请其对下一个 chunk 进行追加请求。

• 第7步

• 如果任何副本中的追加操作失败后会触发重试机制，则客户端（client）将重新发起追加请求；在此过程中已成功完成的副本将多发一次请求以完成最终的重试目标；这种机制会导致记录出现重复（注：此处GFS系统无法保证chunk的所有副本在字节层面上完全一致；但会确保数据以原子性的方式至少有一次地被成功地追加）。

7. 一致性模型

GFS遵循一个宽松的一致性模型。文件命名空间的变更（例如文件创建操作）是原子性的；完全由 master 来控制。命名空间锁确保了原子性和正确性、master 操作日志记录了这些操作在整个系统中的执行顺序。

在系统的构建中存在着_权衡_关系，在追求更高统一性的过程中往往会伴随着更为复杂的体系架构以及增加各节点之间的交互量。基于分布式文件系统的实现（GFS）通过降低统一性的强度从而实现了较低的复杂度与更高的运行效率相结合的特点。这使得它特别适合应用于那些对于数据一致性问题较为不敏感的应用场景如搜索引擎核心功能——根据某一关键词进行信息检索即便返回的结果集中存在若干遗漏或者排序有所偏差也不会产生明显的察觉这表明该算法完全适合于此类应用需求；而对于那些对数据一致性和准确性要求极高的场景如银行级别的数据存储则不宜采用此方案。

7.1 读、写、追加的一致性

对于数据修改后的文件 region ，首先有两个定义：

• 相同的副本 (consistent) ：对于一个 chunk ，每个客户能够访问的所有副本内容都是相同的。
  • 明确地表示为 (defined) ：数据修改后的状态保持一致性，并且每个客户可以看到写入操作后的全部内容（换句话说），即能观察到每一步操作修改后的情况。

对于不同类型修改的 region 状态如下图所示：

当一个数据写操作顺利完成且无其他并发操作，则被修改的区域即为该区域：所有客户端都能够访问到此次写入的内容，并体现了数据的一致性。

在完成并行修改之后的阶段中,region 处于一个保持一致状态的同时却处于未定义阶段: 所有的 client 可以看到完全相同的数据,但无法还原任何一段实际被写入的数据（因为可能存在多个并发操作覆盖了同一个区域）

由于失败的写操作所引发的结果是区域处于不一致的状态（同时也是一个未定义的状态）。各个 client 在不同时刻呈现不同的数据情况。

当对文件执行追加操作时，在追加操作顺利完成的情况下，则会使得 region 被明确且一致地定义；然而，在某次追加操作未能完成的情况下，则根据本文6.3条款可知，在重新请求后会导致数据填充以及出现重复数据的问题，并因此使得 region 被明确但不一致地定义。

某次追加失败过程：

C1 向副本 S1 、S2 中追加 a ，若向 S2 中追加 a 时失败，修改后结果为：

S1 - | a |
S2 - | |

此时 C2 并发地向 S1 、S2 中追加 b ，在两副本相同偏移位置追加，执行成功，修改后结果为：

S1 - | a | b |
S2 - | | b |

之后 C1 由于有副本追加失败，重新发起追加 a 的请求，此次追加成功，修改后结果为：

S1 - | a | b | a |
S2 - | | b | a |

可以看到，重复请求使得 S1 中有了重复记录，使得 S2 中有了填充数据（ 那个空白 ），这就导致了这块 region 是 defined （ 每步修改都能看到 ），但是 inconsistent （ 不同副本数据不一样 ）

8. 垃圾回收

GFS 在文件删除后会延迟地进行回收可用的物理空间，在这种情况下,GFS 空间回收遵循惰性原则，并仅在文件和 chunk 级别的常规垃圾收集阶段执行。

删除时间戳

每当某个程序执行删除操作时,master 都会立即在日志中记录这一事件。但是，在完成此次操作后,master 选择保留一段时间后再回收资源——具体来说,它会将原始文件名重命名为带有【删除时间戳

当 master 执行常规 scan 操作于 chunk 空间时，在遇到未被任何文件包含的 orphaned chunk（即不被任何文件包含的 chunk）后会触发相关处理流程。具体而言，在此过程中, chunkserver 会根据检测结果发出删除指示. 此外, 在隐藏文件尚处于彻底删除状态之前, 可以通过指定新的名称进行读取操作. 此外, 还可以通过重命名操作恢复其原始状态.

这种垃圾回收方式的优势 ：

对于组件失效已成为常态的大规模分布式系统上而言,这种垃圾回收机制具有高效稳定的特性。
该垃圾回收机制将存储空间的回收操作整合到 master 节点定期执行的任务序列中（例如,在 master 节点与 chunkserver 进行协调时完成），通过批量处理减少单个操作的影响,从而降低了资源消耗。
该机制通过延缓存储空间回收为意外删除事件提供了一个恢复的可能性,从而确保数据恢复的可能性得以实现。

9. 容错与诊断

9.1 过期失效的副本检测

该系统通过给每个块（Chunk）分配版本号来区分当前副本与已过时的副本。该系统定期执行垃圾回收流程，在此过程中删除所有已过时且失效的副本。

失效副本 ：在 chunkserver 失效的时候，其 chunk 副本可能会因遗漏某些修改而无法生效。

• 每当 master 将 chunk 分配一个 lease 时 ，其 versions 版本号随之提升 。随后通知所有最新副本 ，master 和这些副本都会将此 latest 最新 version 记录在硬盘上 。
• 如果某个副本所属的 chunkserver 发生故障 ，则该副本的所有 version 版本都不会再升级 。
• 当该 chunkserver 重新启动并汇报其拥有的 chunks 及对应 version 数时 ，master 在收到汇报后会识别出已过期的 chunks 。

每当 master 向 client 发送与 primary 相关的信息时（不论是 master 直接发送还是来自某个 chunkserver 进行复制），消息中包含版本编号。客户端或 chunkserver 在执行操作时都会检查这个版本号以确保始终使用最新的数据。

9.2 快速恢复

• 无论 master 和 chunkserver 的关闭方式如何，在短时间内恢复到正常工作状态并重新启动服务器。不区分是否为正常关闭或异常关闭。
• 当 master 发生灾难性故障时，在发生灾难性故障后会加载最新的备份数据，并模拟这些数据及其相关的日志记录以实现系统修复。
• chunkserver 重启完成后会向 master 发送当前 chunk 的状态信息及版本号。

9.3 chunk复制

• chunkserver 在空闲的时候也会检查不活跃的 chunk 内容。
  当数据损坏发生时 master 会创建一个新的正确的副本并且删除损坏的副本。
  每个 chunk 会被复制到不同的机架上。
  用户可以根据文件空间的不同部分设置不同的复制级别。

9.4 master 的复制

所有操作日志和快照文件被复制至多台机器的硬盘里 。当 master 进程所在的机器或硬盘出现故障时，在其他存有完整操作日志的机器上会重新启动一个新的 master 进程，并且这些新启动的操作日志和快照文件会被同步到现有的主存储位置。

它还支持在 master 挂起时为文件系统提供只读访问。
它启动的时候也会定期查询 chunkserver 以获取数据，并主动地通过握手机制获取状态信息。
只有当 master 因创建或删除副本而导致副本位置信息发生更新时, shadow master 才会与 master 进行通信以更新自身状态。

9.5 数据完整性

每个 chunkserver 分别管理 checksum 用于验证保存的数据的完整性。 checksum 同时存储在内存及硬盘上，并且操作日志中也会存储。

对于读操作来说：

在发送数据给 client 或其他 chunkserver 之前,** chunkserver 会对涉及的数据块进行完整性校验,即检查这些块是否一致。如果某个副本的数据块不一致, chunkserver 将向请求者发送一个错误信息,并通知主节点这一问题。
作为结果,请求者会从其他副本获取相关数据, master 服务器则会复制这些数据以进行修复。
当新副本完成构建后, master 节点会发出指令让 chunkserver **删除那些不再有效的副本。

9.6 诊断工具

• GFS 服务器会生成大量日志数据 ，这些数据包括启动与关闭等关键事件以及其他所有RPC请求与应答的信息 。通过模拟所有消息交互过程可以诊断系统问题 。这些日志数据可用于评估系统的负载情况并进行性能分析 。

10. GFS 的优点

• 主节点（master）与分片服务器（chunkserver）的角色划分实现了文件管理职责与存储管理职责的职责分离。
  • 按chunk划分存储结构后，并发访问支持良好，并能承受较大的吞吐量。
  • 在数据更新过程中实现业务流与数据流的解耦，在提升系统性能的同时充分释放机器带宽。
  • 通过资源leasing策略减少主节点的工作负载负担，并有效防止split-brain故障现象。
  • 增强对随机追加及顺序读取操作的支持功能。
  • 系统具备良好的容错机制。

11. GFS 的缺点

仅有一个 master ，当大量元数据存在时可能会导致内存不足。
当 client 数量极大时 ，一个 master 负载过大 ，会导致单个 master 负载过重。
无法自动重启的 master 出现故障后需手动切换 ，这种情况下人工切换耗时较长。
通过遍历所有 chunk 实现垃圾回收可能会导致效率低下。
不擅长处理随机 writes 以及 处理海量 small files 的存储需求。
一致性过松的系统无法应对对一致性要求严格的场景。
The GFS protocol is specifically designed for use within a single data center's infrastructure.