linux ext3 fsck必定要慎用

做者： 张宇，北亚 硬盘数据恢复中心，转载请联系做者，若是实在不想联系做者，至少请保留版权，谢谢。

 

    　不论是哪一种文件系统，其根本目的都是相同的：如何把文件存在系统给定的区域里，如何有效地管理文件的读与写。为实现这样的目的，驱动层须要完善、周密地应付附加在文件系统上的各类操做。这些操做一般不会是一条指令完成的，若是一个过程须要多条指令完成，在执行这些操做时，所有指令未完成的状况下产生中断，那这个文件系统便会出现一致性错误(或者叫连续性错误)。

　　为了保证尽能够少的出现一致性错误，如今主流的文件系统都会设计成日志型的。日志型文件系统的主要特色就是把一个操做的全部指令执行过程都另外缓冲下来，若是所有执行完成再清除日志标志，若是操做没有执行完成，能够在从新激活后经过日志回溯或继续完成。

　　EXT3的日志功能经过在EXT2的设计基础上增长一个特殊的文件(一般是８号节点文件)，在这个文件中记录文件系统的操做过程。但EXT系统文件系统自己在节点、间接索引块、目录节点方面没有冗余保护，因此当文件系统除日志外的其余结构并不一致，却又要经过fsck来进行修复，这种一致性有可能将本来正确的结构也错误化。(就像原来是1+2=3，如今错成了1+3=3，也许改完后变成了1+3=4，就彻底没办法还原成最先的1+2=3)。

　　数据恢复领域常常会遇到这类状况：一次RAID出故障后，下次启动系统提示作fsck，但作完后，也没法mount分区或者mount 分区后数据全是错的。须要对这类状况进行数据修复的难度是很大的，从一个完整的结构(fsck后实际上从系统角度看已是完整的了)再构建另外一个彻底不一样的结构要比修正一个错误的结构更难如下手。其实这类状况，不少是由于RAID5有早离线的盘加入了两个逻辑磁盘组，致使全部的数据流是以新+旧的方式交错组成的，天然会有太多错误。这时候若是作fsck后，有可能数据都没法恢复了。

　　因此，在EXT3（实际上其余文件系统也相似）没法mount，或者提示fsck时，若是有重要数据，应该慎重对待，千万不可贸然执行"fsck -f -y　"这样的自动修复功能。若是可能，先对故障区域作dd全镜像后再执行，或者以只读方式执行，并仔细看修复过程，若是提示大量inode错误、须要重建树、或大小不对等就不可再继续下去了。