为了满足当今社会数据持续增长的需求，数据大小成几何式的快速增长。我们渐渐进入了“大数据”时代，Google公司面临着几百TB的数据存储。然而目前现有的系统无法满足数据持续增长的需求，Google希望能够开发出一个系统，能够利用一些廉价的单机机器，共同存储PB级别的数据。在能够满足存储海量数据的同时，还能提供灾难容错的能力。
Google设计并实现了GFS文件系统，一个面向大规模数据密集型应用的、可伸缩的分布式文件系统。GFS虽然运行在廉价的普遍硬件设备上，但是它依然了提供灾难冗余的能力，为大量客户机提供了高性能的服务。
图3-1 GFS系统架构[1]
在GFS系统架构中，GFS由Master-Slave架构构成。其中Master用来接收客户端的请求， Master节点管理所有的文件系统元数据。这些元数据包括名字空间、访问控制信息、文件和Chunk的映射信息、以及当前Chunk的位置信息。GFS存储的文件都被分割成固定大小的Chunk。在Chunk创建的时候，Master服务器会给每个Chunk分配一个不变的、全球唯一的64位的Chunk标识。Chunk服务器把Chunk以Linux文件的形式保存在本地硬盘上，并且根据指定的Chunk标识和字节范围来读写块数据。出于可靠性的考虑，每个块都会复制到多个Chunk块。
客户端将需要访问的数据文件名字以及需要访问文件的偏移量在本地进行计算，通过Chunk的大小，客户端计算得到需要访问的Chunk index。然后客户端将文件名字和需要访问的Chunk index发送给Master服务器。Master服务器接收这些请求，然后根据Master服务器上的Matadata信息、以及Chunk的映射信息。Master服务器将需要访问的Chunk位置(Chunk在哪些ChunkServer服务器上)和Chunk Handle发送给GFS client。GFS client根据每个Chunk的位置映射信息以及Chunk的地址请求偏移量访问相应的ChunkServer服务器，然后和ChunkServer服务器建立连接，进行数据传输。如果相应的ChunkServer服务器宕机或者故障，GFS Clinet可以访问相应的Chnnk的副本所在的ChunkServer服务器。GFS通过Master保存的元数据信息，降低了Master的负载，为大量客户机提供了高性能的服务。
GFS选择较大的Chunk尺寸有几个重要的优点。首先，它减少了客户端和Master节点通讯的需求，因为只需要一次和Mater节点的通信就可以获取Chunk的位置信息，之后就可以对同一个Chunk进行多次的读写操作。这种方式对降低我们的工作负载来说效果显著，因为我们的应用程序通常是连续读写大文件。即使是小规模的随机读取，采用较大的Chunk尺寸也带来明显的好处，客户端可以轻松的缓存数TB的工作数据集所有的Chunk位置信息。其次，采用较大的Chunk尺寸，客户端能够对一个块进行多次操作，这样就可以通过与Chunk服务器保持较长时间的TCP连接来减少网络负载。第三，选用较大的Chunk尺寸减少了Master节点需要保存的元数据的数量。这就允许我们把元数据全部放在内存中。
GFS分Chunk来进行存储主要有以下几个原因。
- 首先分Chunk来进行存储，主要原因是GFS被设计是用来存储大文件的。将一个大文件划分为多个Chunk小文件，并且这些多个Chunk是被分布在多个Slaves中。这样可以大大提高系统的整体吞吐量，可以让多个client并行的读取文件，多个client直接互不干扰。
- GFS分Chunk来进行存储，还有一个更重要的原因就是。Chunk是可以进行副本的，通过大文件被划分为多个Chunk，每个Chunk还能有多个副本。当其中一个机器故障，机器中的Chunk被丢失。但是由于Chunk默认是有三个副本的，其中一个Chunk丢失，Client可以访问其他副本的Chunk。GFS通过副本的机制提供灾难冗余的能力，为分布式文件系统提供高性能、高可靠的服务。