linux fack 文件系统修复命令

【简介】

fsck命令被用于检查并且试图修复文件系统中的错误。当文件系统发生错误四化，可用fsck指令尝试加以修复。

【选项】
必要参数
 -a 非互交模式，自动修复
 -c 检查是否存在有损坏的区块。
 -C<反叙述器> fsck.ext3命令会把全部的执行过程，都交由其逆向叙述，便于监控程序
 -d 详细显示命令执行过程
 -f 强制进行检查
 -F 检查文件系统之前，先清理该保存设备块区内的数据
 -l<损坏区块文件> 把文件中所列出的损坏区块，加入标记
 -L<损坏区块文件> 清除所有损坏标志，重新标记
 -n 非交互模式,把欲检查的文件系统设成只读
 -P<数字>  设置fsck.ext2命令所能处理的inode大小为多少
 -r 交互模式
 -R 忽略目录
 -s 顺序检查
 -S 效果和指定“-s”参数类似
 -t  显示fsck.ext2命令的时序信息。
 -v 显示详细的处理过程
 -y 关闭互动模式
选择参数
 -b<分区第一个磁区地址>  指定分区的第一个磁区的起始地址/Super Block
 -B<区块大小>  设置该分区每个区块的大小
 -I设置欲检查的文件系统，其inode缓冲区的区块数目
 -V显示版本信息

【适用】
1) 文件系统：ext2 ext3 reiserfs xfs等
2) 范围：提示文件系统需要FSCK时，未执行或FSCK执行完成

【症状】
1) 无法MOUNT分区;
2) 大量文件、目录丢失，根目录下生成/LOST+FOUND文件夹，里面有大量#XXXXXX类的文件和目录;
3) fsck很快报错完成;
4) fsck执行时，有大量提示，如修改节点、清0节点等操作

【应急】
1，如遇提示fsck时，要小心，如果可能，请尽快断开系统，umount所有分区
2，必须执行fsck时，先做准备工作，方法一：可实现用dd命令所有涉及到的分区输出到另外的存储体上，命令大致所示：dd if=/dev/sda1 of=/dev/sdb1
3，如上面几种方式均因条件等原因无法执行，但又必须执行时，可小心观察fsck的执行提示(关掉 -a) 如果发现有提示节点错误需更正或清0，节点描述文件大小不正确等信息，应停止执行fsck
【备注】
1，如果可能，先对故障区做dd全镜像备份后在执行，或者以只读方式自行，并仔细看修复过程，如果提示大量inode错误，需要重建树、或大小不对等就不可再继续下去了
2，文件系统常见错误，并且问题通畅原因是电源失败，硬件失败，或者操作失误，例如没有正常关闭系统
3，fsck只能运行于为mount的文件系统，不要用于已mount的文件系统
4，修复完成后，会出现提示“FILE SYSTEM WAS MODIFIED”。这时重启系统

【参考范例】

手动fsck修复

　　fsck不仅可以对文件系统进行扫描，还能修正文件系统的一些问题。值得注意的是fsck 扫描文件系统时一定要在单用户模式、修复模式或把设备umount后进行。
　　警告：如果扫描运行中的系统，会造成系统文件损坏。
　　文件系统扫描工具有 fsck，fsck.ext2，fsck.jfs，fsck.msdos，fsck.vfat，fsck.ext3，fsck.reiserfs（reiserfsck）。其中fsck 默认支持文件系统ext2，如果想支持ext3文件系统的扫描，应该加-j 参数。最好是根据不同的文件系统来调用不同的扫描工具，比如ext3的文件系统使用fsck.ext3，ext2文件系统使用fsck.etx2等。

/dev/sdb1是ext3的文件系统，只介绍fsck.ext3

范例1： 检测磁盘
[root@linux test]# fsck.ext3 /dev/fd0
范例2： 检测磁盘并显示时序信息
[root@linux test]# fsck.ext3 -ft /dev/fd0

查看fsck报错的日志
[root@server ~]# ls -l /var/log/fsck/
total 8
-rw-r----- 1 root adm 190 2011-06-09 10:03 checkfs
-rw-r----- 1 root adm 192 2011-06-09 10:03 checkroot
这两个文件中会出现fsck的报错信息。
[root@server ~]# more /var/log/fsck/checkfs
[root@server ~]# more /var/log/fsck/checkroot

查看当前的运行级别：
fsck.ext3扫描文件系统时一定要在单用户模式、修复模式或把设备umount后进行。如果扫描运行中的系统，会造成系统文件损坏。
选择在单用户模式下运行
# runlevel  ---查看运行级别
[root@server ~]# runlevel
N 2
#init 1  --单用户模式（1 S），在转换成单用户模式时可能会需要输入root密码。
[root@server ~]# init 1

使用fsck.ext3对文件系统进行扫描、修复
[root@server ~]# fsck.ext3  -y /dev/sdb1  ---开始进入扫描、修正文件系统， sdb1必须umount
注意红色方框，该位置需要输入yes

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错误、需要重建树、或大小不对等就不可再继续下去了。