这是我第一次阅读学术论文，文章中充斥的一些学术名词给我的阅读带来了一些困难，因为此前没有接触过这方面的内容，在同学的帮助下，查阅了一些资料，终于对GFS有了一点认识，写出这一些感悟，文章措辞不严谨之处，希望谅解。
提到分布式系统，就算是外行人的我都知道Google的三驾马车，GFS正是之一。GFS是一个大型的分布式文件系统，它为Google 的云计算提供海量的存储，成为所有核心技术的底层。GFS将整个系统的节点分为三类：Client（客户端）、Master（主服务器）和Chunk Server（数据块服务器）。Client是GFS提供给应用程序的访问接口，它是一组专用接口，以库文件的形式提供。应用程序直接调用这些库函数，并与该库链接在一起。Master是GFS的管理节点，在逻辑上只有一个，它保存系统的元数据，负责整个文件系统的管理，是GFS文件系统中的核心。Chunk Server负责具体的存储工作。数据以文件的形式存储在Chunk Server上，Chunk Server的个数可以有多个，它的数目直接决定了GFS的规模。GFS将文件按照固定大小进行分块，默认是64MB，每一块称为一个Chunk，每个Chunk都有一个对应的索引号，且是唯一不变的。
与传统的分布式系统一样，GFS 同样追求高性能、高可靠性、高可用性，但同时 Google 基于自身的生产环境、技术环境，有一些自身独有的特点。首先，组件失效是常态化的，而非意外。在 GFS 成百上千的集群中，随时随地都可能发生故障导致机器无法恢复，所以，有一定的容灾、自动恢复能力是必须要整合在 GFS 中的。其次，文件巨大，GB 级别的数据非常普遍。第三，绝大多数文件的写操作都是追加，而非修改，通常的文件场景是顺序写，且顺序读。第四，应用程序和文件系统 API 的协同设计提高了整个系统的灵活性。
一个GFS集群由一个master和大量的chunkserver构成，并被许多Client访问，只要资源和可靠性允许，chunkserver和client可以运行在同一个机器上。与每个应用相联的GFS客户代码实现了文件系统的API并与master和chunkserver通信以代表应用程序读和写数据 。client与master的交换只限于对metadata的操作，所有数据方面的通信都直接和chunkserver联系 。client和chunkserver都不缓存文件数据,由于数据太多无法缓存。不缓存数据简化了客户程序和整个系统，因为不必考虑缓存的一致性问题，但用户缓存metadata。Chunkserver 也不必缓存文件，因为块是作为本地文件存储的。只有一个master也极大的简化了设计并使得master可以根据全局情况作出先进的块放置和复制决定。但是我们必须要将ma ster对读和写的参与减至最少，这样它才不会成为系统的瓶颈。Client从来不会从master读和写文件数据。client只是询问master它应该和哪个chunkserver联系。client在一段限定的时间内将这些信息缓存，在后续的操作中client直接和chunkserver交互。
当今的时代，是大数据的时代，截止到2012年,数据量已经从TB级别跃升到PB、EB乃至ZB级别，人类生产的所有印刷材料的数据量是200PB,全人类历史上说过的所有话的数据量大约是5EB，而到了2020年,全世界所产生的数据规模将达到今天的44倍，因此，可以说没有GFS就没有今天的大数据时代。
以上就是一只菜鸡对一篇论文的简单认识，如有错误之处，希望大佬们帮忙指正。