Hadoop 0.21.0 中的Append/Hflush/Read 说明

From： https://issues.apache.org/jira/browse/HDFS-265
在Hadoop 0.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层的best effort，即不可靠）
  -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的数据都适用