DataNode节点中的存储路径会分别存储不同的文件数据块。HDFS对节点存储路径的实现被抽象成了一个StorageDirectory类。
StorageDirectory文件
StorageDirectory类主要包含三个属性:
File root; // 节点存储目录所在本地文件系统的目录 dfs.data.dir中配置的一个本地路径 FileLock lock; // 排它锁，同步控制节点对该存储目录的操作 in_use.lock StorageDirType dirType; // namenode 或者datanode
root目录下的文件结构在上一篇中已经介绍过了.不过datanode和namenode的目录存放的文件是不同的
无论是NameNode节点还是DataNode节点，StorageDirectory都会把它们出过来的数据保存到自己的子目录current/下，同时为了保证数据的一致性，在子目录current/下都会有一个版本文件VERSION。但是，NameNode节点和DataNode节点的存储目录下的版本文件VERSION的内容有一点不同，如
NameNode存储目录的版本文件：
DataNode存储目录的版本文件：
在HDFS集群中，每一个DataNode节点的每一个存储路径的namespaceID必须与NameNode节点的namespaceID保持一致，否则该DataNode节点将中止启动，NameNode节点的namespaceID在它format是生成，也就是说NameNode节点没格式化一次，就会产生一个新的namespaceID。另外，storageID是DataNode节点向NameNode节点第一次注册时，NameNode为它分配的一个分布式存储器标识，一个DataNode节点中所有存储路径的storageID是一样的。当然，NameNode和DataNode的存储路径中存储的数据文件也是不一样的。
StorageDirectory事务
StorageDirectory除了提供保存节点数据的功能外，还提供了对存储数据的粗粒度事务操作如：备份/恢复/提交等。那么，StorageDirectory是如何实现这些事务性操作的呢
分析状态和恢复
当节点在执行上面操作的某一个过程中突然宕机了，那么这个节点在下一次启动如何进行恢复上一次的中断操作呢？其实，StorageDirectory在在恢复它存储的数据之前会先分析自己所出的状态(analyzeStorage()方法)，然后根据自己当前作出的状态来执行相应的恢复操作(doRecover()方法)。这个分析过程及对应的恢复操作如下：
hadoop的升级和回滚
当在一个已有集群上升级Hadoop时，像其他的软件升级一样，可能会有新的bug或一些会影响到现有应用的非兼容性变更出现。在任何有实际意义的HDSF系统上，丢失数据是不被允许的，更不用说重新搭建启动HDFS了。HDFS允许管理员退回到之前的Hadoop版本，并将集群的状态回滚到升级之前。更多关于HDFS升级的细节在升级wiki上可以找到。HDFS在一个时间可以有一个这样的备份。在升级之前，管理员需要用bin/hadoop dfsadmin -finalizeUpgrade（升级终结操作）命令删除存在的备份文件。下面简单介绍一下一般的升级过程：
1.升级 Hadoop 软件之前，请检查是否已经存在一个备份，如果存在，可执行升级终结操作删除这个备份。通过dfsadmin -upgradeProgress status命令能够知道是否需要对一个集群执行升级终结操作。
2.停止集群并部署新版本的Hadoop。
3.使用-upgrade选项运行新的版本（bin/start-dfs.sh -upgrade）。
4.在大多数情况下，集群都能够正常运行。一旦我们认为新的HDFS运行正常（也许经过几天的操作之后），就可以对之执行升级终结操作。注意，在对一个集群执行升级终结操作之前，删除那些升级前就已经存在的文件并不会真正地释放DataNodes上的磁盘空间。
5.如果需要退回到老版本
- 停止集群并且部署老版本的Hadoop。
- 用回滚选项启动集群（bin/start-dfs.h -rollback）。
参考url
http://blog.jeoygin.org/2012/03/hdfs-source-analysis-3-datanode-storage.html
http://caibinbupt.iteye.com/blog/282580
http://caibinbupt.iteye.com/blog/282735