在Hadoop 2.0 中HDFS 引入了 append 和 hflush 功能之后，
需要为 数据块增加新的状态 来尽最大可能的保证数据的一致性。
参阅文档：
http://files.cnblogs.com/inuyasha1027/appendDesign3.pdf
http://stackoverflow.com/questions/10121705/differences-between-hflush-hsync-apis-in-hdfs
为了更好地区分 位于DataNode上面的 block 与位于NameNode上面的 block，
我们将位于DataNode上面的 block 称之为 replica，
位于NameNode上面的 block 称之为 block。
在 append 和 hflush 功能增加之前， 在DataNode上面的 replica 仅处于
1.finalized 2.temporary 这两种状态。
当一个 replica 首次被创建的时候， 它在Datanode上面的状态是 temporary的。
当接收到来自于客户端的 close 命令的时候， 也就是不会向 该 replica 中写入任何数据的时候，
这个 块（replica）的状态将会从 temporary 状态转换 为 finalized状态。
对于处于temporary状态的replica （位于Datanode上的数据块）在Datanode重新启动的时候，
将会被从相关的路径中进行移除。 由于HDFS为处于 under-construction 状态的blocks
要尽最大努力提高它们的数据持久性，所以在 append 和 hflush 功能 被添加之前，这个是可以接受的。
("这个"：指的是 在datanode restart 之后，将会把处于temporary状态的 replica全部删除，
但是，试想一下，增加 追加 （append） 功能之后，待 datanode重启之后，
就莫名其妙的把 处于temporary 状态的 replicas 给删除，会造成很多数据丢失的)
但是，在引入append 和 hflush 功能之后，这么做就行不通了。
因为 HDFS 需要为 处于 under-construction状态下的保存了在append 操作之前的 data 的blocks
提供高保证的数据持久性 以及尽最大可能为hflush 中的 data提供 持久性。
所以与先前不同，需要改进的地方就是，即便是 Datanode 重新的启动，也要尽量保证 这些处于
temporary状态的 replicas 也是不会被 removed的 而是 被 preserved 的。
下面就介绍一下，在Datanode上面，在引入 append /hflush 功能之后，所新增的
replica的各种状态
1. Finalized：/完成状态
处于这种状态的 replica 有着固定不变的 bytes。 处于 finalized状态的 replica 是不允许
向其中写入数据的，除非对他执行appen操作 使其重新开启（reopened）。
处于finalized 状态的 block中的 data 和 meta data 数据是相互匹配的。
这个 replica 在不同地方的 冗余备份 和 该 replica 的 replica ID是相同的。
但是， 生成时间戳 并不是保持不变的。
2. Rbw（Replica Being Written to）:/ 等待写入状态
一旦一个 replica 被创建 或是被追加（appended），
它就会转换为 rbw 状态。
处于 rbw 状态的replica 是允许 数据被写入的。
在文件系统中，一个文件 对应的是一个 INodeFile 实体， 而该INodeFIle实体中有一个LocatedBlock
的数组，该数组中存放的是 位于DataNode上面的所有 存储文件block的分布情况，
如果该文件正处于被追加状态的话，那么一定是向 该文件对应的INodeFile中的 LocatedBlock 中
的最后一个 block进行写入处理， 这样的话， 这个处于 最后一个 位置的block的状态 一定是
rbw状态的。 上面提到的block 实质上指的是 replica， 由于该文件没有被写完，所以文件长度未定，
该块 replica 的长度也是 未定的。
所以对于存放在 物理介质上的 块中的 data 和meta data 中的数据时不匹配的。
位于不同节点 拥有相同 ID 的 冗余 块 多多少少 与 该块中的数据 也是不一致的。
处于 rbw 状态下的replica 中的部分数据duireaders 是可见的。
为了防止任何错误的发生， 在rbw 状态下的 replica 中的数据 会尽量的被保留的。
3. Rwr （Replica waiting to be recovered）:/ 等待恢复状态
如果一个Datanode 死掉 或是重新启动的话， 处于该datanode上面的所有 rbw 状态的 replicas
都会从 rbw 状态转换 为 rwr 状态。
Rwr 状态下的 replicas 不会出现在 任何 pipeline中， 因此 也不会接受任何新的写入数据。
对于处于Rwr 状态下的replicas 要么成为 过期数据，
要么参与一次 租约恢复操作（如果和datanode 建立 租约（lease）的client 同样挂掉的话） .
4. Rur （Replica Under Recovery ）: /处于恢复状态
当一个 replica 开始恢复直到 租约到期的时候，该replica 将会转为 state 状态。
5. Temporary： 一个处于temporary状态的 replica 同样 也是 当该replica
是 under-construction 状态的时候， 但是有所不同的是：
rbw： 对应的是 client 向 Datanode中写操作而造成的 该replica 是 under-construction
而 temporary： 对应的是 datanode之间的冗余备份 或是 整个集群的负载均衡操作 造成的。
处于 temporary 状态的 replica 与 rbw 状态 的replica 中共享着很多的 属性，
但是还是有所不同
不同1.处于 temporary 状态的 replica 中的 数据对任何 reader 都是 不可见的。
不同2.处于temporary 状态的 replica 如果 创建失败 或是 该replica 所在的 datanode 重启的话，
该 replica 会被 删除，而 rbw 会从 rbw 状态转换为 rwr 状态即等待被 恢复状态。
上述就是，位于 datanode上面的block ： replica 的几种状态。
在 DataNode的数据目中共有三个子目录：
1. current
在这个目录中 保留着 所有处于finalized状态的replicas
2.tmp
在这个目录中保留着 处于temporary状态的replicas，
3.rbw
在这个目录下 保留着 处于 rbw、rwr和rur 状态的replicas。
-----------------------------------------------------------------------
所以，在HDFS接收到来自DFS(client端)创建 replica 的消息， 创建一个replica之后，
该replica首先是被存放在rbw 目录下面的。
而当一个replica 首次被创建，是用于 datanodes 之间的冗余 备份 或是 负载均衡的目的的话，
这个replica 将会被 存放到tmp 目录下面。
一旦一个 replica 被完成之后，即 finalized ，它就会被移动 到 current 目录的下面了。
----------------------------after restart--------------------------------------------
当一个DataNode重新启动之后，位于tmp 目录下面的 replicas将会被删除;
而位于 rbw 目录下面的所有 replicas 将会 被转换为rwr状态;
而位于current 目录下面的 replicas 将会 被正常 加载 且 为 finalized 状态。
下图为 datanode 上面的 block（replica ）的状态转换图：
