由于系统在运作时谁也说不准啥时硬件或者是电源会有问题,所以『当机』可能是难免的情况(不管
是硬件还是软件)。 现在我们知道文件系统运作时会有磁盘与内存数据异步的状况发生,因此莫名其
妙的当机非常可能导致文件系统的错乱。 问题来啦,如果文件系统真的发生错乱的话,那该如何是
好?就...挽救啊!不同的文件系统救援的指令不太一样,我们主要针对 xfs 及 ext4 这两个主流来说
明而已喔!
xfs_repair处理XFS文件系统
回到顶部
当有 xfs 文件系统错乱才需要使用这个指令!所以,这个指令最好是不要用到啦!但有问题发生时,
这个指令却又很重要...
[root@initroot ~]# xfs_repair [-fnd] 装置名称
选项与参数:
-f:后面的装置其实是个文件而不是实体装置-n :单纯检查并不修改文件系统的任何数据 (检查而已)
-d :通常用在单人维护模式底下,针对根目录 (/) 进行检查与修复的动作!很危险!不要随便使用
范例:检查一下刚刚建立的 /dev/vda4 文件系统
[root@initroot ~]# xfs_repair /dev/vda4
Phase 1 - find and verify superblock...
Phase 2 - using internal log
Phase 3 - for each AG...
Phase 4 - check for duplicate blocks...
Phase 5 - rebuild AG headers and trees...
Phase 6 - check inode connectivity...
Phase 7 - verify and correct link counts...
done
# 共有 7 个重要的检查流程!详细的流程介绍可以 man xfs_repair 即可!范例:检查一下系统原本就有的 /dev/centos/home 文件系统
[root@initroot ~]# xfs_repair /dev/centos/home
xfs_repair: /dev/centos/home contains a mounted filesystem
xfs_repair: /dev/centos/home contains a mounted and writable filesystem
fatal error -- couldn't initialize XFS library
xfs_repair 可以检查/修复文件系统,不过,因为修复文件系统是个很庞大的任务!因此,修复时该文
件系统不能被挂载! 所以,检查与修复 /dev/vda4 没啥问题,但是修复 /dev/centos/home 这个已经
挂载的文件系统时,嘿嘿!就出现上述的问题了! 没关系,若可以卸除,卸除后再处理即可。Linux 系统有个装置无法被卸除,那就是根目录啊!如果你的根目录有问题怎办?这时得要进入单人 维护或救援模式,然后透过 -d 这个选项来处理! 加入 -d 这个选项后,系统会强制检验该装置, 检验完毕后就会自动重新启动啰!不过,完全不打算要进行这个指令的实做... 永远都不希望实 做这东西...
fsck.ext4 处理 EXT4 文件系统
回到顶部
fsck 是个综合指令,如果是针对 ext4 的话,建议直接使用 fsck.ext4 来检测比较妥当!那 fsck.ext4
的选项有底下几个常见的项目:
[root@initroot ~]# fsck.ext4 [-pf] [-b superblock] 装置名称
选项与参数:
-p :当文件系统在修复时,若有需要回复 y 的动作时,自动回复 y 来继续进行修复动作。
-f :强制检查!一般来说,如果 fsck 没有发现任何 unclean 的旗标,不会主动进入
细部检查的,如果您想要强制 fsck 进入细部检查,就得加上 -f 旗标啰!
-D :针对文件系统下的目录进行优化配置。
-b :后面接 superblock 的位置!一般来说这个选项用不到。但是如果你的 superblock 因故损毁时,
透过这个参数即可利用文件系统内备份的 superblock 来尝试救援。
一般来说,superblock 备份在:1K block 放在 8193, 2K block 放在 16384, 4K block放在 32768
找出刚刚建置的 /dev/vda5 的另一块 superblock,并据以检测系统
[root@initroot ~]# dumpe2fs -h /dev/vda5 | grep 'Blocks per group'
Blocks per group:
32768
# 看起来每个 block 群组会有 32768 个 block,因此第二个 superblock 应该就在 32768 上!
# 因为 block 号码为 0 号开始编的!
[root@initroot ~]# fsck.ext4 -b 32768 /dev/vda5
e2fsck 1.42.9 (28-Dec-2013)
/dev/vda5 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 1577 has zero dtime.
Fix y>? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/vda5: ***** FILE SYSTEM WAS MODIFIED *****
# 文件系统被改过,所以这里会有警告!
/dev/vda5: 11/65536 files (0.0% non-contiguous), 12955/262144 blocks
# 好巧合!使用这个方式来检验系统,恰好遇到文件系统出问题!于是可以有比较多的解释方向!
# 当文件系统出问题,它就会要你选择是否修复~如果修复如上所示,按下 y 即可!
# 最终系统会告诉你,文件系统已经被更改过,要注意该项目的意思!已预设设定强制检查一次 /dev/vda5
[root@initroot ~]# fsck.ext4 /dev/vda5
e2fsck 1.42.9 (28-Dec-2013)
/dev/vda5: clean, 11/65536 files, 12955/262144 blocks
# 文件系统状态正常,它并不会进入强制检查!会告诉你文件系统没问题 (clean)
[root@initroot ~]# fsck.ext4 -f /dev/vda5
e2fsck 1.42.9 (28-Dec-2013)
Pass 1: Checking inodes, blocks, and sizes
....(底下省略)....
无论是 xfs_repair 或 fsck.ext4,这都是用来检查与修正文件系统错误的指令。注意:通常只有身为
root 且你的文件系统有问题的时候才使用这个指令,否则在正常状况下使用此一指令, 可能会造成
对系统的危害!通常使用这个指令的场合都是在系统出现极大的问题,导致你在 Linux 开机的时候
得进入单人单机模式下进行维护的行为时,才必须使用此一指令!另外,如果你怀疑刚刚格式化成功的磁盘有问题的时后,也可以使用 xfs_repair/fsck.ext4 来检查一磁 盘呦!其实就有点像是 Windows 的 scandisk 啦!此外,由于 xfs_repair/fsck.ext4 在扫瞄磁盘的时 候,可能会造成部分 filesystem 的修订,所以『执行 xfs_repair/fsck.ext4 时, 被检查的 partition 务 必不可挂载到系统上!亦即是需要在卸除的状态喔!』
initroot编辑整理，转载请注明www.initroot.com