The google file system

从这篇论文可以学到：

• GFS的体系结构master-slave模型
• ChunkSize的大小是64MB每个block大小是64KB，基于64KB做checksum
• metadata数据：file和chunk命名空间，映射从文件到chunk，每个chunk复制的位置，所有元数据存在master的内存中
• 数据一致性通过经常handshake来维持
• 当client请求写操作时，master发给其中一个chunkserver一个lease。lease也有order。
• 读数据时候，客户端问master哪个chunkserver它可以读from,参见figure
• 当snapshot时，用户请求一个chunk C的数据。master会让一个有该数据的client复制C的拷贝C'，返回给用户的数据是C'。客户端不会察觉到这个差别。
• 加锁的机制。当写一个目录时候，请求该目录的read锁和该文件的write锁，那就可以保证目录下不会有重名的文件和该文件的写一致性。
• 创建一个chunk放的位置遵循：平均的disk空间使用;限制在某一个chunkserver最近创建文件的数目;复制chunk 跨rack

2 Design Overview

2.2 Interface

GFS有snapshot和record append操作。Snapshot创建一个文件的复制或者目录树在一个低代价。Record允许多个客户端增加数据到相同文件并发地并且保证每个独立客户端增加操作的原子性。有用实现多路merge结果，producer-consumer队列很多客户端可以同时增加不需要额外锁。这些文件在构建巨大分布式应用中具有重大的价值。

2.3 Architecture

一个GFS cluster由一个单独的master和多个chunkserver组成，可以被多个clients访问。每个是一个日用的linux机器运行user-level进程。

2.4 Single Master

必须最小化master参与的读写这样不会变成一个瓶颈。客户端不会从master读写数据。

2.6 元数据

• 在内存中的数据机构。metadata存储在内存中，master操作很快。对于master周期性扫描整个状态在后台也方便和有效。
• chunk的位置 master不会保存一个一致性的记录哪个chunkserver有给定的一个chunk的数据。master在启动时候poll chunkserver这些信息。master能保证这数据是up-to-date因为它和客户端通过HeartBeat信息保持信息的同步。
• 操作日志：重要meta changes的历史记录。由于操作记录很重要，我们复制它在多台机器上。master可以恢复它的文件系统通过重放操作日志。