GFS论文整理(一)
摘要：
?
??? 让我们解释一下一个简单的read操作的交互过程，参见图1.首先，使用固定chunk size，client将应用指定的文件名称和byte offset转换成文件系统的一个chunk索引（filename 和byte offset可以最终确定为某个file中的特定chunk信息）。然后，它（client）向master发送一个包含文件明和chunk索引的请求，master响应给client相应的chunk handle和replicas的位置。Client使用fileName和chunk index作为key来缓存这些信息。
??? 此后client向其中一个replicas发送请求，多数情况下是最近的一个replicas。请求指定了chunk handle和此chunk中的byte range。后续对同一个chunk 的reads将无需与master交互，直到cache过期或者file被重新打开。事实上，client通常会在一次master交互中询问多个chunk的情况，避免了以后client-master的多次交互，事实上也不会带来额外的性能开支。
?
Chunk Size：
??? chunk size是一个关键的设计参数，我们选择了64MB，这个值通常比文件系统的block size要大很多。每个chunk replicas都是作为一个普通的linux文件存储在server上，并且会在需要的时候扩展它。延迟空间分配策略避免了对存储空间的浪费（内部碎片），也许最大的反对点就是这种大尺寸的chunk。
??? 一个大尺寸的chunk你能够提供一些重要的优势。首先，它降低了client与master交互的次数，因为read和write同一个chunk只需要初始时与master一次交互获取chunk位置即可。它的降低，对于我们的workloads来说特别显著，因为应用大多数是顺序的read和write一个大文件。即使一些小的随即度操作（small random reads），客户端能够适当的缓存数TB数据中所有的chunk位置信息。再者，对于一个较大的chunk，客户端能够运行大量操作在此指定的chunk上，它能够通过保持现有的TCP连接（client-->chunkserver的连接）来降低网络开销。第三，它（大尺寸chunk设计）降低了master中metadata的存储尺寸，这就允许我们把metadata存储在内存中，也会带来其他的优势（接下来讨论）。
??? 另一个方面开说，大尺寸chunk，即使采用延迟空间分配，也会有它的缺点。小文件包含少量的chunk，或许只有一个。在多个客户端访问同一个文件时，存储这些chunk的chunkserver可能成为热点（hot spots）。实践中，hot spots还不是一个主要的问题，因为我们的应用大多数情况下是顺序read一个多chunks的大文件。
??? 可是，在hotspots尚未发展时，GFS开始使用的是批量队列系统：一个可执行文件作为一个single-chunk的文件被写入到GFS，然后同时在多个机器上启动。存储这个可执行文件（executeable）的几个chunkservers在数个请求同时访问时可能会过载。我们解决了这个问题，通过使用更高的复制因子（higher replication factor）存储这个执行文件，使被处理队列系统错开应用启动的时间。在这种情况下，一个潜在的解决办法就是允许客户端可以从其他客户端读取数据。（事实上此解决办法是不可取的）
?
Metadata：
??? master存储3个主要类型的metadata：file and chunk namespaces（文件和chunk的命名空间），the mapping from files to chunks（文件与chunk影射关系），the location of each chunks‘ replicas（chunk replicas位置）。这些元数据保存在master的内存中。前2种类型的metadata（namespaces ，file-chunk mapping）也会通过记录变更的方式持久存储一个操作日志文件中（operation log），这个操作日志文件存储在master的本地磁盘并且被replicated在其他的远程机器上（和chunk的机制一样）。有了日志，我们就能够简单而且可靠的去更新master的状态，无需担心master机器crash所带来的不一致问题。
??? 因为metadata存储在内存中，master操作将是很迅速的。此外，对与master后台间歇性扫描整个state也将是很简单和高效的。间歇性扫描，是用来实现chunk回收/重复制故障机器的chunk/chunk迁移（负载均衡，和跨chunkserver磁盘空间使用率）。
??? 这种内存存储方式，有一个潜在的顾虑是chunk的数量，因为整个系统的容量会受到master内存大小的限制。在实践中，这似乎不是一个很严重的限制。每个64MB的chunk，在master中之需要64B的metadata存储，大部分chunk都是满的（full）因为通常一个文件会包含多个chunks，只有最后一个（chunk）是可以被filled（填充数据）。类似，file namespace数据通常只需要少于64B的数据，因为它（master）存储file names会进行前缀压缩。
??? 如果需要支撑更大的文件系统，那么给master机器增加内存也是很简单和廉价的。因此将metadata内存储存，可以获得灵活性/性能/可用性/简易性等。
?
Chunk位置：
??? master不会持久存储chunkserver所持有的replicas信息，它（master）仅仅是在启动后去各个chuankserver上poll这些数据，然后会保持自己所持有chunk信息的更新，因为它控制了所有chunk位置分配，以及使用定期的heartbeat消息监控chunkserver的状态。
??? 我们起初尝试过在master上持久存储chunk位置信息，但是我们觉得master启动时从chunkserver请求这些数据然后间歇性同步的设计更加简单。这样可以避免一些问题：保持master和chunkservers的同步（chunkserver的加入，离群），修改名称失败，重启等等。在一个具有数百台机器的分布式环境中，这些情况还是会经常发生的。
??? 可以从另一个方向来认识这种设计，chunkserver上是否持有chunk，chunkserver具有最终决定权。那就没有必要在master中再持久存储一份视图数据，而且chunkserver的一些error会导致chunk信息的丢失（硬盘损坏或者不可用），甚至有的操作会重命名chunkserver。
GFS论文整理(二):[http://shift-alt-ctrl.iteye.com/blog/1842286]
GFS论文整理(三):[http://shift-alt-ctrl.iteye.com/blog/1842509]
GFS论文整理(四):[http://shift-alt-ctrl.iteye.com/blog/1842510]
