ACM通信

实践

GFS:快进进化

作者:柯克·麦库斯克，肖恩·昆兰
ACM通讯，2010年3月，Vol. 53, No. 3, 42-49页
10.1145/1666420.1666439
评论

在谷歌开发的早期阶段，最初的想法并不包括构建新文件系统的计划。当公司的爬网和索引系统的早期版本正在开发时，核心工程师们很清楚他们真的没有其他选择，因此谷歌文件系统(GFS)诞生了。

考虑到谷歌的目标是利用廉价的商用硬件构建一个巨大的存储网络，因此必须假设组件故障将成为常态，这意味着持续监控、错误检测、容错和自动恢复必须成为文件系统的一个组成部分。此外，即使根据谷歌最早的估计，系统的吞吐量需求也将是令人生畏的，以任何人的标准为特征的几gb的文件和包含tb级信息和数百万对象的数据集。显然，这意味着必须重新审视关于I/O操作和块大小的传统假设。还有可扩展性的问题。这是一个绝对不像其他文件系统那样需要扩展的文件系统。当然，在早期，没有人能够想象到需要多大的可伸缩性。他们很快就会知道的。

尽管如此，近十年后，谷歌的大多数令人难以置信的数据存储和不断增长的应用程序仍然依赖于GFS。在此过程中，对文件系统进行了许多调整，并在使用gfs的应用程序中实现了相当数量的调整，这使得整个过程成为可能。

为了探究一些更关键的初始设计决策背后的原因，以及自那时以来所做的一些增量调整，Sean Quinlan被要求揭开谷歌不断变化的文件系统需求和不断发展的思维的秘密。由于Quinlan曾担任GFS技术领袖数年，现在仍是谷歌的首席工程师，他很有资格提供这种观点。作为谷歌总部之外的一个支点，柯克·麦库斯克(Kirk McKusick)被要求主持讨论。他最著名的工作是在BSD(伯克利软件分发)Unix，包括伯克利FFS(快速文件系统)的最初设计。

本文首先讨论了将初始GFS实现建立在单主机设计上的非正统决定。乍一看，单一集中式主机成为带宽瓶颈的风险更糟，单点故障似乎是相当明显的，但事实证明谷歌的工程师有他们的理由做出这个选择。

MCKUSICK:原始GFS架构中一个更有趣和更重要的方面是决定将其建立在单一主架构上。你能告诉我们是什么导致了这个决定吗?

昆兰:使用单一主控制器的决定实际上是最初的决定之一，主要是为了简化整体设计问题。也就是说，从一开始构建一个分布式master就被认为太困难，需要太多时间。此外，通过采用单主机方法，工程师能够简化许多问题。拥有一个中心位置来控制复制、垃圾收集和许多其他活动肯定比在分布式基础上处理这一切更简单。所以我们决定把这些数据集中在一台机器上。

MCKUSICK:这主要是关于能够在合理的短时间内推出一些东西吗?

昆兰:是的。事实上，一些参与了早期工作的工程师后来继续构建了BigTable，这是一个分布式存储系统，但这项工作花费了很多年。围绕单一主机构建最初的GFS的决定确实帮助我们以比其他方式更快的速度将内容交付给用户。

此外，在勾画出他们预期的用例时，单主机设计似乎不会造成太大的问题。他们当时考虑的规模是几百tb和几百万个文件。事实上，这个系统一开始运行得很好。

MCKUSICK:但然后呢?

昆兰:一旦底层存储的大小增加，问题就开始出现。从几百tb到拍字节，再到几十拍字节……这确实需要主服务器维护的元数据量相应地增加。此外，扫描元数据查找恢复等操作都随数据量的增加而线性扩展。因此，master所需的工作量大幅增加。保存所有这些信息所需的存储容量也在增长。

此外，这被证明是客户端的瓶颈，即使客户端本身很少发出元数据操作，例如，客户端在打开时就会与主服务器对话。当有数千个客户端同时与主服务器通信时，如果主服务器每秒只能执行几千个操作，那么普通的客户端每秒就无法命令那么多的操作。还要记住，在像MapReduce这样的应用程序中，您可能突然有1000个任务，每个任务都想打开一些文件。显然，处理所有这些请求将花费很长时间，并且主服务器将处于相当大的压力之下。

MCKUSICK:现在，在GFS的当前模式下，每个单元有一个主服务器，对吗?

昆兰:这是正确的。

MCKUSICK:历史上每个数据中心都有一个cell，对吧?

昆兰:这是最初的目标，但在很大程度上并没有实现，部分原因是单主机设计的局限性，部分原因是隔离被证明是困难的。因此，人们通常在每个数据中心使用不止一个cell。我们还做了我们称之为多单元方法，基本上可以将多个GFS主服务器放在块服务器池的顶部。这样，块服务器就可以配置为有8个GFS主服务器，如果你愿意的话，这至少会给你一个底层存储池，上面有多个主服务器。然后应用程序负责跨这些不同的单元对数据进行分区。

MCKUSICK:假设每个应用程序都有自己的主程序，主程序负责管理自己的小文件系统。这是基本的想法吗?

昆兰:嗯，是也不是。应用程序倾向于使用一个主程序或一小组主程序。还有一种叫做名称空间的东西，这是一种非常静态的命名空间分区方式，人们可以用它来对实际的应用程序隐藏所有这些。日志处理系统提供了这种方法的一个例子:一旦日志耗尽了只使用一个单元的能力，它们就会移动到多个GFS单元;名称空间文件描述如何跨这些不同的单元对日志数据进行分区，基本上用于对应用程序隐藏准确的分区。但这些都是静态的。

MCKUSICK:考虑到这一切，演出怎么样?

昆兰:我们最终花了相当多的精力来调优主性能，谷歌不太会花大量的工作来调优任何一个特定的二进制文件。通常情况下，我们的方法只是让事情运行得相当好，然后将重点转向可伸缩性，这通常很好，因为你通常可以通过可伸缩性来恢复性能。因为在这个例子中，我们有一个开始对操作产生影响的瓶颈，但是，我们觉得投入一点额外的精力来减轻主服务器的重量是值得的。在从数千个操作扩展到数万个甚至更多的过程中，单个主机的瓶颈程度有所降低。在这种情况下，更多地关注一个二进制文件的效率肯定有助于让GFS运行得比其他情况下更久。

可以说，在创纪录的时间内让GFS准备生产本身就是一种胜利，通过加速谷歌上市，这最终极大地促进了公司的成功。一个三人小组负责了所有这些，包括GFSand的核心，以及在不到一年的时间内准备部署的系统。

但是，一旦规模和用例有时间扩展到远远超出任何人可能想象的范围，任何成功的系统都会付出这样的代价。在谷歌的案例中，这些压力被证明是特别强烈的。

尽管各组织没有交换文件系统统计数据的习惯，但可以肯定的是，GFS是运行中最大的文件系统(事实上，甚至在谷歌收购YouTube之前，这可能就是事实)。因此，尽管GFS的最初架构师认为他们已经为至少几个数量级的增长提供了足够的支持，谷歌却迅速超越了这个数量级。

此外，GFS需要支持的应用程序的数量很快就激增了。在与GFS最初的架构师之一Howard Gobioff的一次采访中(就在他2008年初英年早逝之前)，他回忆道:“我们所有最早版本的GFS最初的消费者基本上就是这个巨大的爬行和索引系统。当我们的质量团队和研究小组开始积极地使用GFS时，第二波到来了，基本上，他们都希望使用GFS来存储大型数据集。不久之后，我们便拥有了50名用户，他们都需要时不时地获得一些支持，以便能够更好地与他人一起玩游戏。”

谷歌不仅构建了文件系统，还构建了在其上运行的所有应用程序，这对我们有很大的帮助。虽然在GFS中不断进行调整，使其更适应所有新的用例，但在开发应用程序时，也考虑到了GFS的各种优点和缺点。Gobioff总结道:“因为我们创造了一切，所以我们可以在任何时候随心所欲地作弊。”“我们可以在应用程序空间和文件系统空间之间来回解决问题，然后解决两者之间的协调问题。”

然而，纯粹的规模问题需要一些更实质性的调整。一种应对策略是在网络中使用多个“单元”，其功能基本上是相关但不同的文件系统。除了帮助处理规模的直接问题外，这被证明是一种对广泛分散的数据中心的操作更有效的安排。

快速增长还对原始GFS设计的另一个关键参数施加了压力:选择将64MB作为标准块大小。当然，这比典型的文件系统块大小大得多，但这只是因为谷歌的爬行和索引系统生成的文件异常大。但是，由于应用程序的组合随着时间的推移而变化，必须找到一种方法，让系统有效地处理所需远低于64MB的大量文件(例如，考虑Gmail)。问题不在于文件本身的数量，而在于集中主机上所有这些文件的内存需求，因此暴露了原始GFS设计中固有的瓶颈风险之一。

MCKUSICK:我从GFS的原始论文[在2003年ACM操作系统原理研讨会论文集文件数量对你来说一直是一个重要的问题。你能再深入一点吗?

---

可以说，在创纪录的时间内让GFS准备生产本身就是一种胜利，通过加速谷歌上市，这最终极大地促进了公司的成功。

---

昆兰:由于人们最终围绕GFS设计系统的方式，文件计数问题很早就出现了。让我举一个具体的例子。在谷歌工作的早期，我参与了日志处理系统的设计。我们最初有一个模型，前端服务器会写一个日志，然后我们基本上会复制到GFS进行处理和存档。开始的时候还不错，但是后来前端服务器的数量增加了，每天都要滚动日志。与此同时，日志类型的数量也在增加，然后前端服务器将经历崩溃循环并生成更多的日志。因此，我们最终得到的文件比基于最初粗略估计的预期要多得多。

这成了我们必须密切关注的领域。最后，我们不得不承认，我们不可能在文件数量持续增长的情况下存活下来。

MCKUSICK:让我确保我的理解是正确的:您的文件数增长问题是由于您需要在主服务器上为每个文件提供一段元数据，并且该元数据必须能够容纳在主服务器的内存中。

昆兰:这是正确的。

MCKUSICK:在主服务器耗尽内存之前，您只能容纳有限数量的文件?

昆兰:完全正确。有两个元数据。一个标识文件，另一个指出支持该文件的块。如果您有一个只包含1MB的块，那么它将只占用1MB的磁盘空间，但是它仍然需要主服务器上的这两位元数据。如果您的平均文件大小最终低于64MB，那么主机上的对象数量与存储中的对象数量的比率就会开始下降。这就是你遇到问题的地方。

回到日志的例子中，当我们在做粗略的估计时，我们很快发现我们所想到的自然映射是完全有意义的，但结果却完全不能接受。我们需要找到一种解决这个问题的方法，即找出如何将一些底层对象组合到更大的文件中。以日志为例，这并不是火箭科学，但确实需要很多努力。

MCKUSICK:这听起来像是过去IBM只有最小磁盘分配的时候，所以它提供了一个实用程序，让您将一堆文件打包在一起，然后为其创建一个目录。

昆兰:完全正确。对于我们来说，每个应用程序最终都在不同程度上做到了这一点。事实证明，与其他应用程序相比，这对某些应用程序来说负担较小。对于我们的日志，我们并没有真正计划删除单个日志文件。更有可能的是，我们最终将重写日志，以匿名化它们或按照这些思路做其他事情。这样，就不会出现在只删除一个包中的一些文件时可能出现的垃圾收集问题。

然而，对于其他一些应用程序，文件计数问题更为严重。很多时候，对于某些应用程序来说，最自然的设计就是不适合GFSeven，尽管乍一看，您可能会认为文件计数完全可以接受，但这最终会成为一个问题。当我们开始使用更多的共享单元时，我们对文件计数和存储空间都设置了配额。到目前为止，人们最终遇到的最大限制是文件数配额。相比之下，底层存储配额很少被证明是一个问题。

MCKUSICK:你想出了什么长期策略来处理文件数问题?当然，分布式主服务器似乎并不能解决这个问题——如果主服务器仍然需要在内存中保存所有的元数据的话。

昆兰:分布式主机当然允许您根据您愿意投入的机器数量增长文件数量。这当然有帮助。

分布式多主模型的一个吸引力在于，如果你把所有东西都放大两个数量级，那么降低到1MB的平均文件大小将与平均64MB的文件大小有很大的不同。如果最终小于1MB，那么还会遇到其他问题，这些问题确实需要注意。例如，如果您最终必须读取10,000个10KB文件，那么您将比只读取100个1MB文件执行更多的查找操作。

我的直觉是，如果你设计的平均文件大小为1MB，那么它应该比假设平均文件大小为64MB的设计提供更多的东西。理想情况下，您可以想象一个系统可以一直缩小到更小的文件大小，但是1MB在我们的环境中似乎是一个合理的折衷。

MCKUSICK:为了让GFS能够处理1MB的文件，你做了哪些工作?

昆兰:我们还没有对现有的GFS设计做任何事情。我们的分布式主系统将提供1MB的文件，这基本上是一个全新的设计。这样，我们就可以将目标定在每个主服务器上大约有1亿个文件。你也可以有数百个大师。

MCKUSICK:所以，基本上没有一个主机会有所有这些数据?

昆兰:这是这个想法。

随着谷歌中BigTable(一种管理结构化数据的分布式存储系统)的出现，一个潜在的解决文件计数问题的方法——尽管可能不是最好的。

然而，BigTable的重要性远远超出了文件计数。具体来说，它被设计成可以跨越数百或数千台机器，扩展到拍字节范围，并且可以轻松地向系统添加更多机器，并在无需重新配置的情况下自动开始利用这些资源。对于一个基于集体力量、潜在冗余和大规模部署商品硬件所固有的规模经济的概念的公司来说，这些确实是显著的优势。

因此，BigTable现在与越来越多的谷歌应用程序一起使用。尽管BigTable与过去有所不同，但必须指出的是，BigTable构建于GFS之上，运行于GFS之上，并且被有意识地设计为与大多数GFS原则保持一致。因此，可以把它看作是一路走来帮助全球预报系统在面对快速而广泛的变化时保持生存能力的主要适应性之一。

MCKUSICK:现在有了这个BigTable。你认为这本身就是一个应用程序吗?

昆兰:从GFS的角度来看，它是一个应用程序，但显然它更像是一个基础设施。

MCKUSICK:如果我理解正确的话，BigTable本质上是一个轻量级关系数据库。

昆兰:它不是一个真正的关系数据库。我的意思是，我们不使用SQL它不支持连接之类的。但是BigTable是一种结构化存储系统，它允许您拥有许多键值对和一个模式。

MCKUSICK:谁是BigTable真正的客户?

昆兰:BigTable越来越多地在谷歌中用于爬行和索引系统，我们在许多面向客户的应用程序中经常使用它。事实的真相是，有大量的BigTable客户端。基本上，任何带有大量小数据项的应用程序都倾向于使用BigTable。在结构化数据的地方尤其如此。

MCKUSICK:我想我在这里真正想提出的问题是:BigTable是否只是作为一种处理小文件问题的尝试而被困在这些应用程序中，基本上是通过将一大堆小的东西聚合在一起?

昆兰:这当然是BigTable的一个用例，但它实际上是用于更一般的问题。如果您以这种方式使用BigTable，也就是说，作为一种解决文件计数问题的方法，而在其他情况下，您可能会使用文件系统来处理这个问题，那么您就不会以任何方式使用BigTable的所有功能。BigTable并不是实现这个目的的理想选择，因为它需要资源来执行自己的操作。此外，它的垃圾收集策略不是特别积极，所以这可能不是使用空间的最有效方式。我想说的是，那些纯粹使用BigTable来处理文件计数问题的人可能不是特别高兴，但毫无疑问，它是人们处理这个问题的一种方法。

MCKUSICK:我所读到的关于GFS的内容似乎表明它的想法是只有两种基本的数据结构:日志和sstable(排序字符串表)。因为我猜sstable必须用于处理键值对之类的东西，这与BigTable有什么不同?

昆兰:主要的区别在于，sstable是不可变的，而BigTable提供可变的键值存储，以及其他很多东西。BigTable本身实际上是建立在日志和sstable之上的。最初，它将传入的数据存储在事务日志文件中。然后它会压实我们把它称为一系列的sstable，随着时间的推移，这些sstable又会被压实在一起。在某些方面，它让人想起日志结构文件系统。无论如何，正如你所观察到的，日志和sstable似乎是我们构建大多数数据的两种底层数据结构。我们有日志文件来记录可变的东西。然后，一旦有了足够的数据，就可以对其进行排序，并将其放入这个有索引的结构中。

尽管GFS没有提供Posix接口，但它仍然有一个相当通用的文件系统接口，因此人们基本上可以自由地编写任何他们喜欢的数据。只是，随着时间的推移，我们的大多数用户最终使用了这两种数据结构。我们还有一个词叫协议缓冲区，这是我们的数据描述语言。在这两种结构中，大多数数据最终成为协议缓冲区。

两者都提供压缩和校验和。尽管公司内部有些人最终重新发明了这些东西，但大多数人只满足于使用这两个基本构件。

因为GFS最初被设计为支持爬行和索引系统，所以吞吐量就是一切。事实上，关于该系统的原始论文对此非常明确:“高持续带宽比低延迟更重要。我们的大多数目标应用程序都要求以高速率批量处理数据，而很少有应用程序对单个读写有严格的响应时间要求。”

但随后谷歌开发或接受了许多面向用户的互联网服务，而这些服务绝对不是这样的。

这立即暴露了GFS的一个缺点，即与最初的单主机设计有关。对于面向批处理的应用程序来说，单点故障可能不是灾难，但对于延迟敏感的应用程序(比如视频服务)来说，这肯定是不可接受的。后来添加的自动故障转移功能有所帮助，但即使这样，服务也可能中断长达一分钟。

当然，GFS的另一个主要挑战是寻找方法，在围绕完全不同的优先级集设计的文件系统上构建对延迟敏感的应用程序。

MCKUSICK:在设计GFS时，最初的重点是批处理效率，而不是低延迟，这一点有很好的文档证明。现在，这又给你带来了麻烦，尤其是在处理视频等事情方面。你是怎么处理的?

昆兰:GFS的设计模型从一开始就是为了实现吞吐量，而不是实现吞吐量所需的延迟。举个具体的例子，如果你在写一个文件，它通常会被写成三重复制，这意味着你实际上要写三个chunkserver。如果某个块服务器死亡或者长时间停顿，GFS主会注意到这个问题并安排我们称之为pullchunk，这意味着它基本上会复制其中一个块。这将使您恢复到3个副本，然后系统将把控制权交还给客户机，客户机将继续写入。

当我们做一个pullchunk时，我们把它限制在每秒5MB10MB的数量级。因此，对于64MB，恢复大约需要10秒。还有许多其他类似的操作可能需要10秒到1分钟，这对于批类型操作来说很好。如果您正在进行一个大型的MapReduce操作，只要其中一项不是真正的掉线就可以了，在这种情况下，您会给自己带来不同类型的问题。不过，一般来说，在一个小时的批处理过程中，一分钟的停顿并不会真正显示出来。但是，如果您正在处理Gmail，并试图编写一个表示某些用户操作的突变，那么停顿一分钟确实会使您陷入困境。

我们的主故障转移也有类似的问题。最初，GFS没有提供自动主故障转移。这是一个手工过程。虽然它并不经常发生，但每当它发生时，电池可能会停机一个小时。甚至我们最初的主故障转移实现也需要几分钟的时间。然而，在过去的一年里，我们已经把时间缩短到了几十秒。

MCKUSICK:不过，对于面向用户的应用程序来说，这是不可接受的。

昆兰:正确的。虽然这些需要提供故障转移和错误恢复的实例在批处理情况下可能是可以接受的，但从延迟的角度来看，对于面向用户的应用程序来说，它们肯定是不行的。这里的另一个问题是，在设计中有一些地方，我们试图通过将数千个操作转储到队列中，然后通过它们进行处理来优化吞吐量。这将带来良好的吞吐量，但对于延迟来说不是很好。你很容易遇到这样的情况:你可能会在队列中被困几秒钟，只是为了排到队列的最前面。

我们的用户群肯定已经从一个基于mapreduce的世界迁移到一个更依赖于像BigTable这样的东西的交互式世界。Gmail就是一个明显的例子。GFS关注的视频并没有那么糟糕，因为你得到的是流数据，这意味着你可以缓冲。尽管如此，在从一开始就被设计为支持更多面向批处理操作的文件系统上构建交互式数据库肯定是一个痛苦的点。

MCKUSICK:你到底是怎么处理的?

昆兰:在GFS中，我们已经设法在一定程度上改进了一些东西，主要是通过设计应用程序来处理出现的问题。以BigTable为例。BigTable事务日志实际上是获取事务日志的最大瓶颈。实际上，我们决定，“好吧，我们将在这些写中看到打嗝，所以我们将做的是在任何时候打开两个日志。然后我们把两者合并。我们会写信给其中一个，如果它卡住了，我们会写信给另一个。我们会在进行重玩时合并这些日志(如果我们需要重玩的话)。”我们倾向于这样设计我们的应用程序，也就是说，他们基本上试图隐藏延迟，因为他们知道下面的系统并不是那么好。

构建Gmail的人使用多宿主模型，所以如果你的Gmail帐户的一个实例卡住了，你就会转移到另一个数据中心。实际上，为了确保可用性，无论如何都需要这种能力。不过，他们这么做的部分动机是想掩盖全球金融系统的问题。

MCKUSICK:我认为可以这样说，通过迁移到分布式主文件系统，您肯定能够解决一些延迟问题。

昆兰:这当然是我们的设计目标之一。此外，BigTable本身是一个非常能感知故障的系统，它尝试以比以前更快的速度响应故障。使用它作为我们的元数据存储也有助于解决一些延迟问题。

参与GFS最早版本的工程师在他们觉得有必要背离传统文件系统设计时并不会特别害羞。恰巧，对一致性所采取的方法是系统中这一点特别明显的方面之一。

当然，这在一定程度上是迫不得已。由于谷歌的计划主要依赖于大规模部署商用硬件，因此故障和与硬件相关的故障是必然的。除此之外，根据GFS的原始论文，还有一些兼容性问题。“我们的许多磁盘对Linux驱动程序声称它们支持一系列IDE协议版本，但事实上，它们只对最近的版本做出可靠的响应。由于协议版本非常相似，这些驱动器大多工作，但偶尔不匹配会导致驱动器和内核不同意驱动器的状态。由于内核中的问题，这可能会悄无声息地破坏数据。这个问题促使我们使用校验和来检测数据损坏。”

然而，这并不意味着任何校验和，而是严格的端到端校验和，从磁盘损坏到TCP/IP损坏再到机器背板损坏。

---

参与GFS最早版本的工程师在他们觉得有必要背离传统文件系统设计的时候并不羞于这样做。恰好，一致性的方法是系统的一个方面，这是显而易见的。

---

有趣的是，对于所有这些检查和警戒，GFS工程团队也选择了一种根据文件系统标准相对宽松的一致性方法。基本上，GFS只是接受了这样一个事实:有时人们会阅读稍微过时的数据。由于GFS主要用作仅追加的系统，而不是覆盖系统，这通常意味着那些人可能会错过一些在他们已经打开文件后追加到文件末尾的内容。对于GFS的设计师来说，这似乎是一个可以接受的成本(尽管事实证明，这在某些应用中是有问题的)。

此外，正如Gobioff解释的那样，“在某些情况下，陈旧数据的风险是高度分布式架构所固有的，因为它不要求主服务器维护所有的信息。如果我们愿意将更多的数据转储到主服务器，然后让它维护更多的状态，我们当然可以让事情变得更紧凑。但这对我们来说真的不是那么重要。”

也许这里更重要的问题是，做出这个决定的工程师不仅拥有文件系统，还拥有打算在文件系统上运行的应用程序。根据Gobioff的说法，“关键是我们控制了水平和垂直的文件系统和应用程序。因此，我们可以确保应用程序知道从文件系统得到什么。我们只是决定把一些复杂性放到应用程序中，让它们来处理它。”

尽管如此，谷歌上仍有一些人怀疑这是否是正确的调用，因为人们有时会在多次读取给定文件的过程中获得不同的数据，这往往与他们对数据存储应该如何工作的整个概念非常不一致。

MCKUSICK:让我们谈谈一致性。问题似乎是，要将所有内容完全写入所有副本可能需要一些时间。我想你之前说过的大意是，GFS本质上要求在你继续之前把这些都写完。

昆兰:这是正确的。

MCKUSICK:如果是这样的话，你怎么可能得到不一致的结果呢?

昆兰:客户的失败往往会把事情搞砸。基本上，GFS中的模型是客户端继续推写操作，直到成功。如果客户端在操作过程中崩溃，事情就会处于不确定的状态。

在早期，这被认为是可以的，但随着时间的推移，我们收紧了这种不一致性可以被容忍的时间窗口，然后我们慢慢地继续减少它。否则，每当数据处于不一致状态时，您可能会得到不同的文件长度。这可能会导致一些混乱。我们必须有一些后门接口来检查这些实例中文件数据的一致性。我们还有一个叫做RecordAppend的东西，它是一个为多个编写者同时追加日志而设计的接口。那里的稠度设计得很松。回想起来，这比任何人想象的都要痛苦得多。

MCKUSICK:到底是什么松了?如果主副本选择了每次写的偏移量，然后确保实际发生;我不知道矛盾会出现在哪里。

昆兰:结果是初选会尝试。它会选择一个偏移量，执行写入操作，但其中一个不会被写入。然后质点可能会改变，这时它可以选择不同的偏移量。RecordAppend也不提供任何重放保护。您可能会在文件中多次获取数据。

甚至在某些情况下，您可以以不同的顺序获得数据。它可能在一个块副本中出现多次，但不一定在所有副本中都出现。如果您正在读取文件，您可以在不同的时间以不同的方式发现数据。在记录级别，您可以发现不同顺序的记录，这取决于您碰巧正在读取哪些块。

MCKUSICK:这是有意为之吗?

昆兰:在当时，这似乎是一个好主意，但现在回想起来，我想大家的共识是，事实证明，这比它的价值更令人痛苦。它只是不能满足人们对文件系统的期望，所以他们最终会感到惊讶。然后他们不得不想出变通办法。

MCKUSICK:现在回想起来，你会有什么不同的处理方式?

昆兰:我认为每个文件有一个写入器更有意义。

MCKUSICK:好吧，但是如果有很多人想要追加到一个log，会发生什么呢?

昆兰:您可以通过单个进程序列化写入，该进程可以确保副本的一致性。

MCKUSICK:还有一种情况是你对一个数据块进行快照。据推测，当你替换一个副本时，或者当某个块服务器宕机，你需要替换它的一些文件时，你就会用到它。

昆兰:实际上，有两件事正在发生。正如您所建议的，一种是恢复机制，它肯定涉及到对文件副本的复制。在GFS中工作的方式是，我们基本上撤销了锁，这样客户端就不能再写了，这是我们讨论的延迟问题的一部分。

还有一个单独的问题，就是支持GFS的快照特性。GFS具有您所能想象到的最通用的快照功能。您可以对某处的任何目录进行快照，然后两个副本将完全相同。他们将分享未改变的数据。您可以更改其中任何一个，也可以对其中任何一个进行进一步快照。所以它更像是一个克隆，而不是大多数人认为的快照。这是一件有趣的事情，但它会造成困难，尤其是当您试图构建更多的分布式系统，并且您可能希望对文件树的更大块进行快照时。

我还觉得很有趣的是，快照功能并没有被更多地使用，因为它实际上是一个非常强大的功能。也就是说，从文件系统的角度来看，它确实提供了一个很好的功能。但是，我相信您知道，将快照放入文件系统是一件非常痛苦的事情。

MCKUSICK:我知道。我做了它。这是痛苦的，特别是在一个覆盖的文件系统。

昆兰:完全正确。在这种情况下，我们没有作弊，但是从实现的角度来看，很难创建真正的快照。不过，在这种情况下，全盘收购似乎是一个正确的决定。同样，这与早期在语义方面做出的其他一些决策形成了有趣的对比。

总而言之，近10年后的GFS的成绩单似乎是积极的。当然，谷歌的成功是有问题和缺点的，但毫无疑问，GFS在其中发挥了重要作用。更重要的是，考虑到谷歌的操作规模已经超过了系统设计处理的任何量级，它的持久力是令人瞩目的，而谷歌目前支持的应用程序组合是任何人在20世纪90年代末都无法想象的。

不过，毫无疑问，GFS现在面临着许多挑战。首先，在最初为批处理系统吞吐量设计的系统上支持不断增长的面向用户的、对延迟敏感的应用程序的尴尬是显而易见的。

BigTable的出现在这方面有一定的帮助。然而，事实证明，BigTable实际上并不完全适合GFS。事实上，它只是使系统的单主机设计的瓶颈限制比其他情况下更加明显。

由于这些原因和其他原因，谷歌的工程师在过去两年的大部分时间里一直在研究一个新的分布式主系统，该系统旨在充分利用BigTable来解决一些被证明对GFS来说特别困难的问题。

因此，现在看来，除了为确保GFS的持续生存所做的所有调整之外，进化树上最新的分支将在未来几年继续增长，具有重要意义。

相关文章
在queue.acm.org

与杰夫·邦威克和比尔·摩尔的对话
http://queue.acm.org/detail.cfm?id=1317400

20年后的五分钟规则:闪存如何改变规则
Goetz Graefe
http://queue.acm.org/detail.cfm?id=1413264

标准化存储集群
Garth Goodson, Sai Susharla, Rahul Iyer
http://queue.acm.org/detail.cfm?id=1317402

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2010 ACM有限公司

---

没有发现记录