Hadoop 0.21.0 中的Append/Hflush/Read 说明
From：https://issues.apache.org/jira/browse/HDFS-265
在Hadoop0.21.0中fsync（API中是DFSOutputStream的sync()方法）操作改名为hflush，原因是它的实际语义是刷新（flush）缓存，而不是同步数据到硬盘，fsync功能（Syncable接口中的hsync方法）可能会在以后的版本中添加（参考：https://issues.apache.org/jira/browse/HDFS-744，https://issues.apache.org/jira/browse/HADOOP-6313定义了三种flush）。
read/write语义不含append/hflush
1、对于打开的文件的数据，DFS尽力提供持久性（ best effort durability ，类似ip层的besteffort，即不可靠）
-NameNode持久化文件元数据信息，但是不持久化文件由哪些块组成的信息，重启NameNode可能会导致数据丢失
-DFS不保证各数据块的副本数和文件的复制因子一致，如果一个数据块没有一个有效副本被写入，则写失败。
2、对于关闭的文件的数据，DFS提供强持久性
-NameNode持久化文件和数据块元数据信息，重启NameNode不会导致数据丢失。
-DFS保证各数据块的副本数和文件的复制因子一致。
-文件关闭不保证数据已经到达磁盘。如果数据未到达磁盘，重启DataNode会导致数据丢失。
3、read
-对于打开的文件数据，只有已完成块（block写满）的数据对readers是可见的。正在写的块中的数据，对reader来说是不可见的
append（追加写入）
1、只允许一个writer/appender ，这表明一个client只能append一个关闭的文件
2、已关闭的文件打开append时，DFS为旧数据提供强持久性，为新append的数据尽力提供持久性（ best effort durability ）
hflush（刷新缓存）
1、hflush保证hflush之前写入的数据对于新的reader都是可见的
-hflush不保证数据同步到磁盘，重启DataNode节点可能造成hflush过的数据丢失
2、对于hflush的数据，DFS只提供弱持久性
-NameNode持久化hflush的数据所属的block的元数据信息，重启NameNode不会导致hflush了的数据的丢失
-DFS不保证各数据块的副本数和文件的复制因子一致
read（读入文件）
1、允许存在多个程序并行地读取未关闭的文件
2、hflush的数据，对于新的新的reader都是可见的
3、writer/appender不调用hflush，reader仍可以看到之前写入的数据，但会有延时
4、如果一个字节对一个reader可见，它就是持续可见的，除非读该字节的所有副本数都失败，所有副本读入都失败将会返回一个error
-这表明一个字节的一个副本对reader可见，那其他副本也可见
-这对于hflush的和没有hflush的数据都适用