GFS由三层组成：GFS客户端，处理程序数据请求;管理服务器，用内存中的索引追踪数据文件名和所在区块的位置;还有数据存储服务器本身。最初， 为简单起见，GFS为每个集群使用一个单独的管理服务器，因此系统被设计成让管理服务器尽可能避开数据访问。谷歌已经发开出了一个分布式管理服务器系统， 可以控制数百台管理服务器，每一台都能处理大约1亿个文件。

当GFS客户端收到一个特定数据文件的请求，它需要从管理服务器请求数据的位置。管理服务器提供其中一个副本的位置，之后客户端就可以直接与存储服务器进行沟通，用来读写剩下的其他部分。管理服务器就不再参与其中了，除非有错误发生。

为确保数据是高度可用的，GFS舍弃了其他一些东西——比如各副本间的一致性。GFS确实坚持数据的原子性——如果写入失败，它将返回一个错误，然 后将写入回滚到元数据，并产生一个旧数据的副本。但是管理服务器在数据写入上的介入缺失意味着当数据写入到系统时，它不能立刻让副本遍布整个GFS集群。 在处理对数据同时访问和网络限制的必要性之外，该系统遵循谷歌所谓的“宽松一致性模型”。

这意味着GFS对于在必要时从旧的副本提供陈旧的数据完全不在乎——只要数据最终得以更新。管理服务器的追踪变化，或“突变”，当变化发生时，区块中的数据会用版本号来指示。由于一些副本被留下了(或变“旧了”)，GFS管理服务器会确保这些区块在更新前不会送至客户端。

但这并不一定发生在已经连接到那些区块的部分。元数据的变更在管理服务器处理这些变更，并将它们反映在元数据前是不可见的。元数据也需要在多个位置 生成副本，以防管理服务器出错——那样的话整个文件系统就丢失了。而且如果在写入过程中管理服务器有错误发生，变更同样会消失。由于谷歌处理数据的方式， 这并不是一个大问题：程序使用的大部分的数据很少变化，而且当变化发生时，数据通常是扩充的而不是原地修改的。

当GFS在为2003年运行的谷歌应用设计出来时，离谷歌开始遭遇扩展性问题并不远。甚至是在公司收购YouTube之前，GFS开始碰壁——很大 原因是谷歌新添加的应用在64M文件大小下工作的不是很好。为了绕过它，谷歌转向了Bigtable，一种基于表格的数据存储，那依稀类似于数据库，位于 GFS之上。Bigtable大多是一次写入，因此变更被作为对表的扩展进行存储的——谷歌将其用于如对Google Docs进行版本控制的类似应用上。

如果你不是在谷歌工作，那上述内容太过于学术性了(虽然它可以帮助AppEngine，谷歌云存储和谷歌其他服务的用户更好地了解台面下是怎么事 儿)。虽然谷歌云存储通过一个网络接口提供了一个公开方式来储存和访问位于GFS上的文件，但是操控GFS的真正接口和工具并不是公开的。但报告称GFS 引领了更广泛使用的分布式文件系统的发展，如：Hadoop分布式文件系统。