基础命令学习目录首页html
本文出自 “airfish2000” 博客,更多命令查看博客:node
http://airfish2000.blog.51cto.com/10829608/1880801linux
fsck命令运维
使用fsck命令能够检查文件系统并尝试修复系统的错误。post
命令语法:linux运维
fsck [选项] [文件系统]学习
命令中各选项的含义如表所示。url
表 fsck命令选项含义spa
选项.net |
含义 |
-a |
自动修复文件系统,不询问任何问题 |
-A |
按照/etc/fstab配置文件的内容,检查文件内所列的所有文件系统 |
-N |
不执行命令,仅列出实际执行会进行的动做 |
-P |
当搭配-A选项使用时,则会同时检查/目录的文件系统 |
-r |
采用交互模式,在执行修复时询问,让用户确认并决定处理方式 |
-R |
当使用-A选项检查全部文件系统的时候,跳过/目录的文件系统 |
-t <文件系统类型> |
指定要检查的文件系统类型 |
-C |
显示完整的检查进度 |
-y |
关闭互动模式 |
-c |
检查坏块,并将它们添加到坏块列表 |
-p |
自动修复文件系统错误 |
-f |
强制检查,即便文件系统被标记干净 |
例:检查磁盘分区/dev/sda5的文件系统。
[root@rhel ~]# fsck /dev/sda5
例:强制检查磁盘分区/dev/sda5的文件系统
[root@rhel~]# fsck -f /dev/sda5
fsckfrom util-linux-ng 2.17.2
e2fsck1.41.12 (17-May-2010)
第一步:检查inode,块,和大小
第二步:检查目录结构
第3步:检查目录链接性
Pass4: Checking reference counts
第5步:检查簇概要信息
/dev/sda5:12/6561792 files (0.0% non-contiguous), 459863/26215641 blocks
例:检查和修复磁盘分区/dev/sda5的文件系统,在执行修复时进行询问,让用户决定处理方式,显示详细修复过程。
[root@rhel ~]# fsck -rV -t ext4 /dev/sda5
例:检查磁盘分区/dev/sda5的文件系统,并显示完整的检查进度。
[root@rhel ~]# fsck -C -t ext4/dev/sda5
例:检查磁盘分区/dev/sda6的msdos文件系统的是否正常,若是有异常便自动修复。
[root@rhel ~]# fsck -t msdos -a/dev/sda6
功能说明:检查文件系统并尝试修复错误。
语 法:fsck [-aANPrRsTV][-t <文件系统类型>][文件系统...]
补充说明:当文件系统发生错误四化,可用fsck指令尝试加以修复。
注意:千万不能在运行的系统上面直接执行fsck,特别是RHEL6.0如下ext3的文件系统,不然100%损坏根文件系统,使用fsck -y /dev/sdb1 修复磁盘时,必须将sdb1分区umount掉
参 数:
-a 自动修复文件系统,不询问任何问题。
-A 依照/etc/fstab配置文件的内容,检查文件内所列的所有文件系统。
-N 不执行指令,仅列出实际执行会进行的动做。
-P 当搭配"-A"参数使用时,则会同时检查全部的文件系统。
-r 采用互动模式,在执行修复时询问问题,让用户得以确认并决定处理方式。
-R 当搭配"-A"参数使用时,则会略过/目录的文件系统不予检查。
-s 依序执行检查做业,而非同时执行。
-t<文件系统类型> 指定要检查的文件系统类型。
-T 执行fsck指令时,不显示标题信息。
-V 显示指令执行过程。
fdisk -l 查看设备号
运行 fsck -y /dev/sdb1 修复磁盘 -y参数为自动确认修复
这条命令也是用fsck修复磁盘是,常使用的命令
特别说明:在EXT3(实际上其余文件系统也相似)没法mount,或者提示fsck时,若是有重要数据,应该慎重对待,千万不可贸然执行"fsck -f -y "这样的自动修复功能。若是可能,先对故障区域作dd全镜像后再执行,或者以只读方式执行,并仔细看修复过程,若是提示大量inode错误、须要重建树、或大小不对等就不可再继续下去了。
不论是哪一种文件系统,其根本目的都是相同的:如何把文件存在系统给定的区域里,如何有效地管理文件的读与写。为实现这样的目的,驱动层须要完善、周密地应付附加在文件系统上的各类操做。这些操做一般不会是一条指令完成的,若是一个过程须要多条指令完成,在执行这些操做时,所有指令未完成的状况下产生中断,那这个文件系统便会出现一致性错误(或者叫连续性错误)。
为了保证尽能够少的出现一致性错误,如今主流的文件系统都会设计成日志型的。日志型文件系统的主要特色就是把一个操做的全部指令执行过程都另外缓冲下来,若是所有执行完成再清除日志标志,若是操做没有执行完成,能够在从新激活后经过日志回溯或继续完成。
EXT3的日志功能经过在EXT2的设计基础上增长一个特殊的文件(一般是8号节点文件),在这个文件中记录文件系统的操做过程。但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错误、须要重建树、或大小不对等就不可再继续下去了。
原文连接:https://blog.csdn.net/ggxiaobai/article/details/53505118
补充说明:当文件系统发生错误四化,可用fsck指令尝试加以修复。
注意:千万不能在运行的系统上面直接执行fsck,特别是RHEL6.0如下ext3的文件系统,
不然100%损坏根文件系统,使用fsck -y /dev/sdb1 修复磁盘时,必须将sdb1分区umount掉