GFS文件系统块规模

　　单master

　　只有一个master也极大的简化了设计并使得master可以根据全局情况作出先进的块放置和复制决定。但是我们必须要将master对读和写的参与减至最少，这样它才不会成为系统的瓶颈。Client从来不会从master读和写文件数据。Client只是询问master它应该和哪个 chunkserver联系。Client在一段限定的时间内将这些信息缓存，在后续的操作中Client直接和chunkserver交互。

　　以图1解释一下一个简单的读操作的交互。

　　1、client使用固定的块大小将应用程序指定的文件名和字节偏移转换成文件的一个块索引(chunk index)。

　　2、给master发送一个包含文件名和块索引的请求。

　　3、master回应对应的chunk handle和副本的位置(多个副本)。

　　4、client以文件名和块索引为键缓存这些信息。(handle和副本的位置)。

　　5、Client 向其中一个副本发送一个请求，很可能是最近的一个副本。请求指定了chunk handle(chunkserver以chunk handle标识chunk)和块内的一个字节区间。

　　6、除非缓存的信息不再有效(cache for a limited time)或文件被重新打开，否则以后对同一个块的读操作不再需要client和master间的交互。

　　通常Client可以在一个请求中询问多个chunk的地址，而master也可以很快回应这些请求。

　　块规模

　　块规模是设计中的一个关键参数。我们选择的是64MB，这比一般的文件系统的块规模要大的多。每个块的副本作为一个普通的Linux文件存储，在需要的时候可以扩展。

　　块规模较大的好处有：

　　1、减少client和master之间的交互。因为读写同一个块只是要在开始时向master请求块位置信息。对于读写大型文件这种减少尤为重要。即使对于访问少量数据的随机读操作也可以很方便的为一个规模达几个TB的工作集缓缓存块位置信息。

　　2、Client在一个给定的块上很可能执行多个操作，和一个chunkserver保持较长时间的TCP连接可以减少网络负载。

　　3、这减少了master上保存的元数据(metadata)的规模，从而使得可以将metadata放在内存中。这又会带来一些别的好处。

　　不利的一面：

　　一个小文件可能只包含一个块，如果很多Client访问改文件的话，存储这些块的chunkserver将成为访问的热点。但在实际应用中，应用程序通常顺序地读包含多个块的文件，所以这不是一个主要问题。