以下纯属散记，属于片面知识记录，如无阅读过对应论文《Google File System》请勿往下阅读。
GFS适用于以下场景
1 认为组件失效是一种常态，提供了容错机制，自动负载均衡，使得分布式文件系统可以在廉价机器上运行
2）面向大文件存储，系统主要的工作负载是大规模的流式读取，写操作主要是追加方式写，很少有随机写
3）一次写入，多次读取，例如互联网上的网页存储
首先大概客户端拿chunk的信息图如下：
从上面的图我们可知道，客户端会先从master服务器拿到对应的chunk地址索引，然后缓存在客户端本地，直接去chunk那里请求，而不需要经过master。
但是什么是master?
GFS中的master是专门用于存储chunk元数据及监控chunk状态的中心服务器，只有一台，但会将其备份同步到多台服务器中。而chunk则是该分布式文件系统存储文件的地方，默认是64M作为一个chunk，一个对应的文件可能存在多个chunk。
问题来了，小的文件含更少的chunk，这可能会导致如下问题
假设这个文件仅含一个chunk，那容易造成热点问题，什么是热点问题，简单的来说是大量客户端老是请求这个地方，导致服务器过载之类问题。
解决的方案：1 将当前chunk复制多几个备份用于给这些客户端访问，这样就能将大量的请求分散到多个服务器。
2 客户端相互之间共享数据。
类似上面，如果采用方案1，原则上是可行的。但是如何确保当前副本chunk数据会一致？
这些就要从GFS的租约，版本号，命名空间锁之类的简单讲解了。先不急，下面慢慢展开说
首先要了解Mater究竟存储了什么，是怎么拿到这些存储数据？
master存储了元数据如下三种：
- 文件与chunk命名空间
- 文件和chunk对应关系
- chunk复本位置
由上可知，元数据均与Chunk相关，其chunk信息获取途径如下：
1 Master启动时或有新的Chunk加入时，就会轮询所有chunk查他们的信息
2 Master为了确保chunk比较新，会心跳监控C服务器的状态，定时更新
3 M中数据被持久化后会保存操作日志，并将操作日志同步到多台远程机器用于灾难恢复
了解了Master存了什么，接下来可以说说究竟怎么同步副本chunk的
GFS中master会与新建的chunk建立一个有期限的租约，并且增加其版本号。当客户端请求master时，master会将对应chunk的版本号和复本位置相关信息返回去，客户端缓存该chunk信息，然后请求对应chunk时会对比版本号，如果不正确则当作失效，然后删除。如果版本号对比正确并且时写入操作，则写入到Chunk上，并且根据当前chunk规定的位置同步到所有的副本chunk(中间如果有同步失败，那版本号就不对了，下次肯定被发现失效删除了)。
上面简单说了他是怎么同步的，但是同步的过程中还有一个锁确保了其操作范围
假设有一个目录为：d1/d2/d3/.../dn/leaf (其中leaf是最里面的目录)
这时候请求chunk需要操作的是leaf，我们就会获取leaf的读写锁，上层如d1...dn这些拿到的都是读锁。这样我们就可以避免误操作上层无关目录，因为没有写权限，只有读权限。
说完上面，说下chunk副本的一些用途
chunk副本有三种用途如下：
- 创建
- 重新复制
- 重新负载均衡
以上这三个用途是为了实现以下原则：
- 平衡硬盘使用率(在低于硬盘平均使用率的服务器上创建新的副本chunk)
- 限制同一节点操作次数
- 机架间分布副本
以上简单的来说是限制次数，每个服务器的硬盘使用率平均点就好了
额外：master节点会移走剩余空间低于平均值的chunk副本，平衡硬盘使用率。
垃圾回收机制
chunk服务器被删除时，master会记录删除日志，并把chunk改为包含删除时间戳、隐藏名字，每次删除会删三天前(默认)的隐藏文件(当然可以通过特殊的方式访问这些未被删的隐藏文件)，并更新master节点元数据
过期失效副本检测(回顾上面所说的chunk副本同步)
master会与chunk签租约，会增加chunk版本号，并更新到chunk副本，若chunk副本失效，版本号则不会被增加。master则检测到版本号不一致将其移除。客户端与chuank交互式也会检查其版本号。
