url: https://pdos.csail.mit.edu/6.824/papers/gfs.pdf

---

Abstract

我们设计并实现了Google文件系统（GFS）——一个面向大规模分布式数据密集型应用的可扩展分布式文件系统。该系统在廉价的商用硬件上运行，既能提供容错功能，又能为大量客户端提供高聚合性能。

虽然与先前分布式文件系统有着诸多共同目标，但我们的设计源自对应用负载特性和技术环境的观察，这些既包含现状也涵盖预期变化，显著区别于早期文件系统的某些假设。这促使我们重新审视传统设计方案，探索根本不同的设计路径。

该文件系统已成功满足我们的存储需求。作为数据生成与处理的存储平台，GFS在谷歌内部被广泛部署：既支撑着服务运营所需的数据处理，也支持需要海量数据集的研发工作。迄今最大的集群包含上千台机器，通过数千块磁盘提供数百TB存储空间，可同时响应数百个客户端的并发访问。

本文中，我们将阐述为支持分布式应用而设计的文件系统接口扩展方案，深入讨论系统设计的多个关键方面，并通过微观基准测试和实际应用场景的数据进行性能评估。
总结：我们设计了一个谷歌内部使用的分布式文件系统，它和传统分布式文件系统有些不同

---

1. INTRODUCTION

我们设计并实现了Google文件系统（GFS），以满足谷歌数据处理需求快速增长的要求。GFS与以往分布式文件系统有许多共同目标，如性能、可扩展性、可靠性和可用性。但我们的设计受到了对当前及预期应用负载与技术环境的关键观察所驱动，这些观察反映出与早期文件系统设计假设的显著差异。我们重新审视了传统选择，在系统设计空间探索了截然不同的方向。

首先，组件故障是常态而非例外。该系统由数百甚至数千台采用廉价商用部件的存储机器组成，被数量相当的客户端机器访问。组件的数量和质量决定了在任意给定时间总有部分组件无法正常工作，有些甚至无法从当前故障中恢复。我们遇到过应用程序错误、操作系统漏洞、人为失误、磁盘/内存/连接器/网络/电源故障等问题。因此，持续监控、错误检测、容错和自动恢复必须成为系统的核心功能。
挑战1：节点故障常常出现

其次，按传统标准衡量文件体积巨大。多GB文件十分常见，单个文件通常包含网页文档等众多应用对象。当我们日常处理由数十亿对象组成、快速增长的TB级数据集时，即便文件系统支持，管理数十亿个约KB大小的文件也极为不便。这要求我们必须重新审视I/O操作和块大小等设计假设与参数。
挑战2：文件体积大、文件数量多是分布式文件系统的挑战，我们需要重新设计 I/O 操作和块大小

第三，多数文件通过追加新数据而非覆盖现有数据来修改。文件内的随机写入几乎不存在。文件一旦写入就只进行读取操作（且多为顺序读取）。各类数据都具有这些特征：有些是分析程序扫描的大型资料库；有些是运行应用持续产生的数据流；有些是归档数据；有些是在某台机器生成、在另一台处理（同步或异步）的中间结果。针对大文件的这种访问模式，追加操作成为性能优化与原子性保证的重点，而客户端缓存数据块则失去意义。
挑战3：根据实践中的观察，大多数文件操作是追加新数据和读取数据，文件内随机写入相对少见。因此，追加操作的性能优化是重点。相对的，在客户端缓存数据块就没有那么有吸引力了。

第四，应用程序与文件系统API的协同设计通过提升灵活性使整体系统受益。例如我们放宽了GFS的一致性模型，在避免给应用增加繁重负担的同时极大简化了文件系统。我们还引入了原子追加操作，允许多客户端无需额外同步即可并发追加文件。这些将在后文详细讨论。
挑战4：TODO

目前多个GFS集群服务于不同用途。最大集群包含逾1000个存储节点、超过300TB磁盘存储空间，持续承受来自数百台独立客户端机器的高频访问。

TODO: here