今晚的罪恶来源于https://issues.apache.org/jira/browse/HDFS-265，里面再次提到了"Lease Recovery"，因为之前在阅读<
wait，琢磨了一下时间线，这里是HDFS支持append的design，那么在这之前，应该也存在LeaseRecovery，引用中提到的内容只是对其的修改和补充，那么
没错，更新版本是0.21.0，那么我直接找它之前的最后一个版本就可以了。
于是在这里找到了
因为搭建源码环境耗时且恶心，所以就直接在Linux上"tar + vim + find + grep"了，下载了0.20.2和0.21.0两个版本进行对比
拿append中的一个类文件作为查找条件，果然：
直接看0.20.2中的LeaseRecovery部分，即src/hdfs/org/apache/hadoop/hdfs/server/namenode/LeaseManager.java，根据HDFS 2.x，LeaseManager拥有一个后台线程Monitor，周期性检查是否需要进行某些客户端的租约回收，于是乎
对应于FsNamesystem.java，跟进去
对应于INodeFileUnderConstruction.java，再跟进去
其实看到这里就可以理清大致思路了，在某一个客户端的租约过期时，LeaseManager会遍历被这个客户端持有租约的所有文件，对于每一个文件，LeaseManager会提取出它最后一个Block，对于这个Block的每一个Replica，会采取轮询的方式选取Replica所在的DN作为PrimaryNode，通过响应DN的HeartBeat，NN将命令以DataCommand[]的形式带回给DN，让这个DN充当PrimaryNode去做Block的完整性检查；然后，如FsNamesystem.java中最后的代码，更新LeaseManager相关的list/map等数据结构。
那么下一个问题来了，DN执行DataCommand的代码在哪里？HDFS2.x中，这部分存在于BPServiceActor，但是这时是针对HA和Federation架构的，在0.20.2这个版本还未出现，于是使用原始的方法：
原始的方法有时也很快捷，跟进去
不出意外，应该是这个case，至于后面这个PrimaryNode都做了什么见不得人的事，且听下回分解；至于在支持Append之后，LeaseRecovery以及BlockRecovery干的勾当，且听下下回分解。
顺便提一句，0.20.2版本的代码，相对于2.x和当前最新的3.x，简直是天堂。另附一张更悲伤的图，来自于3.3.3的Release
