GFS是专为google特定场景（数据处理）下的workload设计的
应用场景
错误是正常现象。使用普通硬件组成群集。
处理文件为大文件。通常为几G。
文件操作，append远比overwrite要多。论文中多次提到使用文件作为mpsc介质。
应用专为design作优化。
首先，假如不看论文，需要考虑的事情
- 文件本身是资源，如果是local file，需要占用磁盘空间、inode、文件名（索引项）。如果是remote file，需要考虑传输、带宽占用、网络拓扑。
- 并发。
- 数据一致性。
- 容错。机器挂掉，磁盘损坏，系统错误。
- 单点故障。
- 并发下可能产生数据overlap。
设计
为了支撑业务需求，gfs支持snapshot、append only。
架构
首先看文件怎么存
文件格式。一个文件大小不定，为了减小recovery time、利用多台机器提高并行度、带宽利用率、处理延时，需要对文件进行切分。GFS本身是为了大文件设计的，所以这里切分成大小64M的chunk。文件与块之间的对应关系单独存储。
文件自身容错。硬件远没有想象的可靠，磁盘本身可能会造成内容损坏，另一方面driver、kernal都可能有bug，一些文件系统在存储时会添加额外的检验。文件本身需要进行自检验，一般使用checksum。
GFS整体上分为两块：master和chunk
master存放filename、file->chunk对应关系、权限，master是单点，由master负责分配chunk 的handle id。
chunk server负责存储数据，对存储的数据分block进行定时checksum、checkpoint操作。同一个chunk通过副本来容错。
master与chunk之前通过心跳来同步数据。
GFS不提供POSIX兼容的文件接口，通过提供library库链接到client端进行操作。
tradeoff
单主 VS consistent hash
存储本身是有状态的，从各个维度来看有不同的状态，single master的一大好处在于拥有所有的状态信息，使用这些信息来驱动新片分配、复本迁移等操作的策略决策。极大地简化了设计，但是有一个很大的前提是master的状态信息要足够地小，不能成为瓶颈。
consistent hash好处，无主进而无单点故障，不受master资源限制。
基本流程
client先根据offset和chunk size，将offset转化为(filename, chunk index)，从master获取chunk元信息，根据元信息去对应的chunk server读取数据。一个优化，获取chunk信息时，额外获取相关的信息进行cache，减少与master的交互。
chunk size，如果过小，会导致chunk量增多，metadata过大。如果太大，会导致小文件场景下浪费磁盘空间。
论文中讲到，hot spot会在特殊场景下产生，通过增加副本数，避免许多机器同时访问（增加jitter)来完成。个人觉得这种方式过于手动化，不scale，还是需要更自动化的方式来实现（检测hotspot，自动扩副本数）。
metadata包括namespace、file chunk mapping、chunk location，所有的metadata是in-memory处理的。metadata的操作通过日志和checkpoint来达到近似事务方式的可靠。通过类似B-tree形式的结构（这里存疑，具体是什么样子的数据结构，metadata逻辑上包括tree、map两种结构）存储checkpoint文件，可以直接mmap进内存进行查询，减少recovery time。
数据一致性
namespace操作，通过在文件目录上每一项逐步加锁来实现一致。
chunk操作，按照论文中的consistent和defined定义，GFS在单client chunk append操作过程中是defined（如果不考虑client端chunk meta info cache影响）。数据操作是通过lease和chunk version来实现的。
单client情况下，使用文件传输完成更名或checkpoint来实现文件处理。
并发情况下，append是at-least-once使用checksum和entity id实现检验和去重。
使用lease（facebook memcache集群也使用lease来解决stale和其它问题，待读）和chunk version来实现数据更改在所有replica上是顺序的。
snapshot使用cow和reference count来实现，master收到snapshot请求之后先撤销对应所有chunk上的lease，等lease撤销或者过期之后，将snapshot操作先写盘，然后拷贝对应的chunk metadata。snapshot操作之后写入时如果rc > 1，先创建新的chunk，再在新的chunk上进行操作。（** 疑问，snapshot如何支持多版本 **）
副本安排目标：尽可能提前磁盘、网络利用率，同时考虑容灾（交换机、机柜、机房、异地网络等）。策略上要考虑副本剩余数、对现有请求影响。
文件删除时，拆分成修改成hidden name、从master的namespace中删除文件名、删除file->chunk对应关系、chunkserver删除数据，基本每一步都是延迟删除，出现意外可以及时撤销，同时分布式系统中出现状态临时不一致是种普遍的事情，延迟删除可以避免中间状态产生意外。使用GC的方式进行延迟删除，可以避免删除附带的负载抖动。
GC可能引起的磁盘利用率高时空闲空间紧张可以通过添加强制删除操作解决。
master的shadow可以提供部分读取功能。
chunk切分成64k的block来计算checksum，checksum是cpu耗时的任务，减少粒度可以避免过多重复计算。读取时会比对checksum。
后续
GFS论文中与master数据一致性相关的内容可以使用paxos、raft之类的一致性协议来完成。
具体实现时，肯定还有很多工程上的细节优化。之后抽时间看下QFS的代码。
