终于下决心来仔细认真的看看Hadoop权威指南，前面三章网上已经有中文版本了，开始从第四章看把，Hadoop I/O，看看自己英文理解能力到底咋样，坚持吧！
Hadoop由一组数据源来数据输入输出。一些技术比Hadoop更加普遍，例如数据完整性和压缩，但是如果遇到处理TB级的数据时候就需要特别的考虑了。其他的Hadoop工具或者API形成了区块为构建分布式系统，例如序列化框架和硬件数据结构。
数据完整性
Hadoop的用户希望没有数据在处理和存储的过程中会丢失和打断。但是，因为在硬盘上或者网络上的每个I/O操作都会有机会产生错误在读或者写时，当通过系统的数据流量是和Hadoop的处理能力一样大的时候，数据出错的机会就变大了。
通常的检查错误数据的方法是计算checksum当第一次进入系统时，然后不论何时数据传递一个不可靠的通道因此产生了错误的数据。数据被认为是损坏的如果新的checksum和最初的不匹配的时候。这个技术不能提供修改数据的方法---仅仅是错误检测。（这是一个原因不用低档次的硬件；尤其是，取用ECC内存）。可能checksum是损坏的，但是这是很不可能的，因为checksum比数据很小的。（怎么看不懂到底讲什么啊）
一个普遍用的错误检测代码式CRC-32（环形冗余检测），它是32位整形的为输入的任何数据大小校验。
在HDFS中的数据完整性
HDFS透明的检测所有的写入的数据并且默认的核对checksum当读数据的时候。一个独立的checksum是为每个io.bytes.per.checksum产生的。默认的是512bt，因为CRC-32是4bt，存储开销就会低于1%。
Date弄的负责在存储数据和checksum之前检查得到的数据。这些应用在复制期间从客户和其他Datanode得到的数据上面。一个写数据的客户发送数据岛datanode的管道，并且在管道的最后的datanode检测checksum。如果检测出错误，客户端会得到ChecksumException，一个IOException的子类。当用户从datanode中读取数据的时候，他们也检测checksum，对比那些存储在datanode的数据。每个datanode保持着一个checksum认证的永久的log，所以就会知道每个没核对的数据块的最后时间。当一个用户成功的检验了一个数据块，它会告诉datanode，就会更新log。记录这些数据在检测错误的硬盘的时候会很有用的。
在用户读取的时候除了数据块认证，每个datanode运行一个DataBlockScanner在后台进程中，它会定期的检测存储在datanode中的所有数据块。这是为了防止因为在物理存储介质上的“bit rot”产生的错误。283页的“Datanode block scanner”描述了怎样得到scanner 报告。
因为HDFS存储数据块的副本，它能“治愈”错误数据块通过复制一个好的副本来产生一个正确的副本。这个工作的方法就是当检查数据块时一个用户检测出一个错误，它会报告错误的数据块并且datanode试图从namenode中读取数据在抛出ChecksumException之前。namenode标记错误的数据块，因此它不会让用户指向错位数据块，或者试图复制副本到其他的datanode中，所以它的副本系数是在可以预见的水平。一旦这种情况发生了，错误的副本就会被删掉。通过传递错误到setVerify Checksum（）方法在文件系统中的checksum的认定失效是可能的，在用open（）方法读文件之前。通过shell命令也可以得到相同的效果，用-ignoreCrc选项通过-get或者相同的-copyToLocal命令。这种特征是有用的如果你想使用损坏的文件。例如，你会想想它是否能在使用在删除之前。
LocalFileSystem
Hadoop的localfilesystem扮演着用户那一边的checksumming。这就意味着如果你写一个名为filename的文件，文件系统用户会透明的产生一个文件，filename.crc,在包含在为文件的每个片的checksum的相同路径中，像HDFS，这个块的大小是被io.bytes.per.checksum属性控制的，默认情况下是512bt。那个组的大小是作为元数据存储在.crc文件中，因此这个块文件能重新读取甚至当这个块的大小改变了。Checksum被核对当文件读取时候，和如果一个错误被检查到。LocalFileSystem会抛出一个ChecksumException。