共计 2913 个字符，预计需要花费 8 分钟才能阅读完成。
Linux 命令：fsck
性能阐明：查看文件系统并尝试修复谬误。
语 法：fsck -aANPrRsTV[文件系统 …]
补充阐明：当文件系统产生谬误时，可用 fsck 指令尝试加以修复。
参 数：
-a 主动修复文件系统，不询问任何问题。
-A 按照 /etc/fstab 配置文件的内容，查看文件内所列的全副文件系统。
文件 /etc/fstab 寄存的是零碎中的文件系统信息。当正确的设置了该文件，则能够通过 ”mount /directoryname” 命令来加载一个文件系统，每种文件系统都对应一个独立的行，每行中的字段都有空格或 tab 键离开。同时 fsck、mount、umount 的等命令都利用该程序。
-N 不执行指令，仅列出理论执行会进行的动作。
-P 当搭配 ”-A” 参数应用时，则会同时查看所有的文件系统。
-r 采纳互动模式，在执行修复时询问问题，让用户得以确认并决定解决形式。
-R 当搭配 ”-A” 参数应用时，则会略过 / 目录的文件系统不予查看。
-s 依序执行查看作业，而非同时执行。
-t< 文件系统类型 > 指定要查看的文件系统类型。
-T 执行 fsck 指令时，不显示题目信息。
-V 显示指令执行过程。
运行 fsck 后，该命令会分 6 个阶段对文件系统
进行查看，这六个阶段别离是：
阶段 1：查看块和块的大小
阶段 2：查看路径名
阶段 3：查看连接性
阶段 4：查看参考记数
阶段 5：查看自在块列表
阶段 6：补救自在块列表
—- fsck 在对每个阶段进行查看时，如果发现错误，会提醒用户进行批改，常见的一些谬误有：1) 移去一个没有相干文件的目录入口
—- 这时用户能够答复 Yes 或 Y 来删除该目录入口。
—- 2) 重连贯一个已调配但不能拜访的文件：
—- fsck 找到了一个已调配的 I 节点，但却不可拜访(该节点没与任何目录连贯)，这时个别对 fsck 的 ”RECONNECT？” 答复 Yes，即把该 I 节点连贯到 lost+found 目录下，文件名即是 I 节点号，之后管理员应查看该文件类型，判明该文件用处，再将该文件拷贝到相应目录下。
—- 3) 连接数调整
—- 在交互方式下，fsck 若发现连接数不统一，将询问用户采取何种口头，本例发现一目录的 I 节点连接数与该目录的实在连接数不统一。
—- 这时用户应该答复 Yes 或 Y 来改过连接数。
—- 4) 自在块表不统一
—- fsck 查出未调配块数与超级块中所给出的自在块表不统一。
—- 这时用户应该答复 Yes 或 Y 来修改超级块。
—- 从下面的出错信息和解决办法能够发现，对于 fsck 询问的问题大多数状况下都能够用 Yes 来答复，所以在理论利用时，能够用 ” -y” 选项来执行该命令对硬盘进行检查和修复。
用 fsck 查看文件系统完整性
文件系统很简单，因而易于产生谬误。能够用 fsck 命令查看文件系统是否正确和无效。它能够依据指令修复找到的小谬误，并将未修复错误报告用户。侥幸的是，文件系统的代码十分无效，所以基本极少呈现问题，并且问题通常起因是电源失败、硬件失败、或操作谬误，例如没有失常关闭系统。大多数零碎设置为启动时主动运行 fsck，因而任何谬误将在零碎应用前被检测到(并依据心愿修改)。应用有谬误的文件系统可能使问题变得更坏：如果数据结构有问题，应用这个文件系统可能使之更糟，导致更多的数据失落。当然，在大的文件系统上运行 fsck 会花肯定的工夫，如果零碎失常敞开，简直从不产生谬误，因而有一些办法能够不进行查看。如果文件 /etc/fastboot 存在，就不查看。另外，如果 ext2 文件系统在超级块中有一个特定的标记告知该文件系统在上次 mount 后没有失常 unmount. 如果标记指出 unmount 失常实现(假如失常 unmount 指出没问题)，e2fsck (fsck 的 ext2 文件系统版) 就不查看零碎。/etc/fastboot 是否影响零碎依赖于你的启动手稿，但 ext2 标记则在你应用 e2fsck 时产生作用 – 基于一个 e2fsck 选项(参阅 e2fsck 手册页)
主动查看只对启动时主动 mount 的文件系统产生作用。==>? 应用 fsck 手工查看其余文件系统，比方软盘。
1、fsck
fsck 是能够说是应用次数第一的工具（零碎本人应用占 90% 以上）。它是 FS 完整性检查，包含 supblk,cylgrpblk,inode.tab,data 区等。查看的原理是：冗余发。修复时依照理论状况调整记录信息。
lost+found 目录：在 fsck 的时候，将找不到父目录的那些文件拷贝到该目录中，并以 i 节点号作为文件名。
当系统启动的时候会应用 fsck 对文件系统进行扫描，并相应的报出扫描后果。例如：/dev/rdsk/c0t0d0s7 stable 等。
前面是 Fs 的状态。其中，clean 示意文件系统 umount 后无人用，stable 示意文件系统用过，但却是残缺的，好的。而出一大堆的话，还有什么 fragment % 什么的的那都示意文件系统上有乱的中央，那么就应该进入零碎后应用 fsck 来整顿。提起这个来，我想说说在非法关机后（各种起因），再次启动的时候会有很多的状况，下面说的是一种状况，再厉害一些是零碎只能进入但用户状态，最厉害的是连单用户的状态都无奈进入（必定是 / 和 /usr 区有问题。这是因为 fsck 对 / 区的扫描无奈通过的话，零碎当然无奈启动，而 fsck 调用的一些函数库又在 /usr 上。。。。）
当零碎的状态是 clean，stable 和 logging 的状态的时候（logging?? 不晓得的看上一课吧）fsck 不运行。
2、fsck 的应用
本课讲的三个参数：
-o f 对系统进行强制查看，不管零碎是否在 clean 等状态
-o p 非交互式查看并修复文件系统，对有的问题则立刻退出
-o b=xx 用来修复超级块的谬误，就是将备份的超级块内容拷入超级块中。solaris 对超级块很器重，它的备份有很多，个别的 b =32 就能够了，如果不行能够应用命令 newfs -N /dev/rdsk/cxtxdxsx 来查看超级块的地位，其中任何一个备份块都可应用
3、一些谬误的状况
一、RECONNECT
示意目录失落，可将其存入 lost+found 中再作转移。答复 yes
二、SUPERBLK 坏（留神是坏，不是 wrong）
修复见下面（如果是 wrong 就轻易了，修不修都能够）
三、CLEAR
删 i 节点，可能会错
四、REMOVE
删文件，个别给出文件名。file=….
五、ADJUST
调整连接数。理论数与原记录不符。答复 yes
六、SALVAGE ====>?
自在列表计数不正确。答复 yes
（题外话：其实我应用个别都是 yes 过来的，而且书上说不能在正在 mount 的文件系统上操作，否则有可能导致文件系统损坏。但我也没有碰到过用 fsck 导致产生谬误的状况。不过还是倡议大家操作的时候标准一些，否则出错了不要来找我呀。尤其是考试的时候
参考链接：
Check Filesystem with Fsck Command in Linux