fsck.ext3开始进入扫描、修正文件系统，这个过程时间比较长，中间有数次停顿的过程，只需等待即可，千万不要以为死机而重启服务器。
fsck.ext3扫描、修正完文件系统后，根据提示可能需要重启系统。如果没有提示重启系统，也需要reboot来重启系统。
[root@server ~]# reboot ---重启系统
在重启系统的过程中，fsck会对文件系统进行扫描，如下：
fsck扫描完以后，会启动到系统的登录界面，不需要进行任何干涉。
再次重新启动系统，系统可以正常启动。
【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错误、需要重建树、或大小不对等就不可再继续下去了。