The Google File System 翻译和理解( 三 ) _生活百科

客户端向其中一个副本发送请求，大多数时候选择最近的那个。请求指定了块句柄和那个块的一个字节范围。后续客户端无需和主节点交互，除非缓存信息过期或文件被重新打开。
事实上，客户端通常在一个请求中询问多个块，主节点的回复也会包含紧跟在请求块后面的块的信息，这在实际中往往可以在未来减少一些客户端-主节点通信。

2.5 块大小块大小是设计的关键参数，我们选择 64MB，这要比一般文件系统的块要大许多。每个块副本在块服务器上被存储为一个普通的 Linux 文件，只有在需要时才扩大。
令块的大小很大的最大隐患在于内部碎片。GFS 使用惰性空间分配避免了因内部碎片带来的空间浪费。
采用大小比较大的块有以下几个重要优点：

它能减少客户端和主节点的交互次数，因为一个块的位置信息代表了更多的数据的位置。
由于大的块大小，客户端能在一个块上进行更多操作。这样可以通过与块服务器在一段时间内保持一个 TCP 长连接赖减少网络开销。
主节点可以存储更少的元数据，这样我们可以把元数据存储在内存中。所带来的好处在 2.6.1 节中讨论。

采用大小大的块也有下面这个缺点：
当大量客户端访问相同的文件时，存储这个块的块服务器会成为热点。显然当块的大小比较大，出现热点块服务器的概率也就更大。
在实际中，热点不是一个主要问题，因为我们的应用大多会顺序读取大量的包含多个块的文件。
但是当 GFS 第一次用于一个批处理序列系统时，还是发生了热点问题：一个可执行文件以单个块的形式写入 GFS，然后在数百台机器上同时启动。少量的存储这个文件的块服务器会由于数百台机器的同时访问而过载。我们通过以下两个手段解决这个问题：

提高可执行文件的复制因子 replication factor 。让更多的块服务器存储这些热点数据。
令批处理序列系统和应用程序不同时，而是交替启动。

一个可能的长期的解决方案是让客户端能从其他客户端读取数据。
2.6 元数据主节点存储了三种主要类型的元数据：文件和块的命名空间，文件到块的映射，以及每个块副本的位置，所有元数据都保留在主节点的内存中。
命名空间，以及文件到块的映射，通过将操作记录存储在本地磁盘上的日志文件中得以永久保存，并在远程的机器上进行日志备份。使用日志使我们能够简单可靠地更新主节点状态，并且不用担心主节点崩溃造成的不一致。主节点不会永久保存块位置信息，而会在启动时，以及有新的块服务器加入集群时，询问每个块服务器的块信息。
2.6.1 内存中的数据结构得益于元数据存放在内存中，主节点的操作非常快。它也能使主节点能够周期性地在后台简单有效的地浏览整个系统的状态。这个周期性的浏览操作用于实现块的垃圾回收、块服务器出错后的重复制，负载均衡和磁盘空间使用的块迁移，4.3 和 4.4 节会深入的讨论这些行为。
但将元数据放在内存中有一个潜在问题，即块的数量和将来整个系统的容量受到主节点的内存大小限制。但由于块的元数据大小实际很小，所以在实际中这不是一个严重的问题。更何况，即使需要为主服务器增加额外的内存，这个花费相比将元数据存放在内存中带来的简单性、可靠性、有效性和扩展性来说，也是很值得的。
2.6.2 块位置主节点不会永久保留类似哪些块服务器含有一个给定的块的记录这样的信息。而是在启动时轮询块服务器获取这些信息。主节点可以将自己保持在最新状态，因为它控制所有块的放置，并且通过常规的心跳消息来监控块服务器的状态。