GFS是Google在2003年发表的一篇论文，虽然Morris在6.824上说这篇论文并没有太多的创新点，但是它成功构建了一个由1000多台廉价机器组成的分布式存储集群，在当时算是技惊四座的存在，于是就被计算机系统领域最顶级的会议接收了。
论文地址：https://pdos.csail.mit.edu/6.824/papers/gfs.pdf
摘要
GFS文件系统是一个面向大规模数据密集型应用、可伸缩(scalable)的分布式文件系统。GFS虽然运行在廉价的普通硬件上，但是它提供了容错机制(fault tolerance)，并且为大量的客户机提供了高性能的服务。
GFS的设计目标与传统的分布式文件系统类似，但是根据谷歌内部的应用负载情况和技术环境作出了一些改变。我们重新审视了传统文件系统在设计上的折衷选择，衍生出了完全不同的设计思路。
GFS满足了谷歌对于存储的需求，并且已经广泛部署在了谷歌内部，存储大量数据的同时还作为大规模数据集的研究和开发工作。在2003年，谷歌最大的集群用几千个硬盘提供了几百T的空间，可以为好几百个客户机服务。
1 简介
谷歌不同于传统分布式存储系统的设计思路如下：
- 将组件崩溃(component failures)视为常态而不是意外，由于GFS运行在成百上千台廉价的存储机器上，所以任何意外都有可能存在，比如应用程序bug，操作系统bug，人为错误，机器故障等等，因此必须将持续的监控、错误侦测、灾难冗余以及自动恢复集成到GFS中。
- 文件大，好几G的文件非常普遍，用管理小文件的方式来管理这些文件肯定不太合适，因此需要重新设计IO操作和Block的尺寸。
- 绝大部分的文件修改是在文件尾部添加数据，而不是覆盖操作。随机写入的操作也基本不存在。一旦文件写入以后，以后基本不会修改，只有读取，而且是按顺序读。对于这些访问模式，客户端对于数据块的缓存没有必要，因此，需要重点考虑的就是数据的追加操作，它是性能优化和原子保证的主要考量因素。
- 应用程序和文件系统API的协同设计提高系统的灵活性。GFS放松了对于一致性模型的要求，采用弱一致性的方式，简化了对于GFS的设计。引入原子性的记录追加操作，来保证多客户端之间数据追加的一致性，而不需要额外的同步操作
2 设计概述
2.1 设计需求
- 组件失效是常态，所以需要好的容错机制
- 能够对大文件进行有效管理，小文件也支持，但是不特殊优化
- 对两种读操作的优化：大规模的流式读和小规模的随机读，在进行随机读的时候，如果程序对性能有要求，可以将随机读合并后排序，这样就可以按顺序批量读，而不需要来回移动
- 对大规模、顺序的、数据追加方式的写操作
- 重视吞吐量，不重视响应时间
2.2 接口
- 类似传统文件系统的分层组织（目录树），用路径名来识别一个文件
- 创建文件、删除文件、打开文件、关闭文件、读和写文件
- 快照（快速实现对于一个文件的拷贝）
- 原子操作在文件尾部追加记录
2.3 架构
一个GFS集群包含一个Master节点，多台chunk服务器，以及需要对数据读写的多个客户端
Master节点虽然说只有一个，但其实只是逻辑上的一个，在实际中可能有好几个，比如主Master服务器，备用的Master服务器和影子Master服务器，如果只有一个Master服务器，那么如果它挂了，集群恢复就会有些麻烦。
Master节点管理所有系统的元数据，包括：
- 名称空间（路径名，以此确定文件）
- 文件与chunk的映射（一个文件会被分割成多个chunk，每个chunk有一个64位的唯一标识，由于这些chunk分散在不同的机器上，所以需要有一个映射表，这样就能知道这个文件是由哪些chunk组成的）
- 当前chunk存储在哪个chunk服务器上
同样它还管理一些活动，包括：
- 周期性地和每个chunk服务器通信，检查它们是否活跃，chunk服务器也会将状态信息报告给Master
- chunk的租用管理
- 孤儿chunk的垃圾回收
- chunk在不同的chunk服务器之间迁移
Comments | NOTHING