Block块

block块大小为什么是128M？

    磁盘寻址时间：10ms左右

    I/O速率：100M/s

    要让文件的寻址时间不会占用太多的文件读写时间，通常是1%；10ms*100 = 1s;所以让

文件块的大小在100M左右，100M转换为二进制就是128M

Block概念：

    磁盘有默认的数据块大小，它是磁盘读/写数据的最小单位。构建在这样的磁盘上的文件系统也是通过磁盘块来管理该文件系统中的块，该文件系统块的大小可以是磁盘块的整数倍。文件系统块一般为几千字节，磁盘块一般为512字节。对于用户来讲对文件的访问/存取都是透明的，同样系统管理员可以利用系统本身的命令对数据块进行相关操作。

    HDFS也有一个块(Block)的概念，不但是大得多，默认为128MB。和一般的文件系统不同的是:虽然块设置得比较大，但是当一个文件的大小小于HDFS的块大小时，实际存储所占的大小并不占用一个块的大小（例如，当一个1MB的文件存储在一个128MB的块中时，文件只使用1MB的磁盘空间，而不是128M）。

问：Block什么时候开始64M，哪个hadoop版本开始的？什么时候开始128M的，哪个hadoop版本？
答：hadoop一开始默认块的大小为64M。hadoop2.x默认块的大小为128M。

 问：Block是在datanode里吗？
 答：应该说NameNode里有block的映射，就是真正的数据是在datanode里，
元数据是在namenode里，同样，对于block也是。所以不能简单地认为，block就是在datanode里，这是片面错误的答法。 
    这么回答 实际数据存在datanode的block里，block的映射（即Block Map）在namenode里，其实对于也有存储在namenode里的，是个相互的嘛。

问：文件系统的块、磁盘块、HDFS的块block有什么区别？
    答：文件系统的块通常是磁盘块的整数倍。文件系统的块一般为几千字节(byte)，磁盘块一般为512字节(byte)。HDFS也有Block的概念，但它的块是一个很大的单元，默认是128M。
    像硬盘中的文件系统一样，在HDFS中的文件将会按块大小进行分解，并作为独立的单元进行存储。但和硬盘中的文件系统不一样的是，存储在块中的一个比块小的文件并不会占据一个块大小盘物理空间（HDFS中一个块只存储一个文件的内容）。

问：为什么HDFS中的块如此之大呢?

    HDFS的Block设计的如此之大，也就是为了最小化寻道时间。把一个数据块设计的足够大，就能够使得数据传输的时间显著地大于寻找到Block所在时间。这样，传输一个由多个Block组成的文件的时间就取决于磁盘的传输速率。

一个常被问到的一个问题是： 如果一个HDFS上的文件大小(file size) 小于块大小(block size) ，那么HDFS会实际占用Linux file system的多大空间？
          答案：是实际的文件大小，而非一个块的大小

 如果hdfs占用Linux file system的磁盘空间按实际文件大小算，那么这个”块大小“有必要存在吗？

    答：其实块大小还是必要的，一个显而易见的作用就是当文件通过append操作不断增长的过程中，可以通过来block size决定何时split文件。

客户端在读取HDFS上的一个文件时就以块为基本的数据单元
　　 例如一次简单读取，首先，客户端把文件名和程序指定的字节偏移，根据固定的Block大小，转换成文件的Block索引。然后，客户端把文件名和Block索引发送给Master节点，Master节点将相应的Block标识和副本的位置信息返回给客户端，客户端用文件名和Block索引作为key缓存这些信息，之后客户端发送请求到其中的一个副本，一般会选择最近的。请求信息包含了Block的标识和字节范围。在对这个Block的后续读取操作中，客户端不必再和Master节点通信了，除非缓存的元数据信息过期或文件被重新打开。实际上，客户端通常会在一次请求中查询多个Block信息，Master节点的回应也可能包含了紧跟着这些被请求的Block后面的Block的信息。在实际应用中，这些额外的信息在不花费任何代价的情况下，避免了客户端和Master节点未来可能会发生的几次通信。