如何使用“fsck”工具修复Linux文件系统错误？

Linux 文件系统负责管理数据的存储与恢复，但随着时间的推移，文件系统可能会因各种原因出现损坏，导致部分数据无法访问。当文件系统出现不一致时，建议立即进行完整性检查。

要检查和修改，可以利用fsck（文件系统一致性检查）的系统工具来完成，该工具会在系统启动时自动检查根文件系统，也可手动运行。

1.什么情况下需要使用 fsck 命令

以下情况或场景下通常需要运行fsck：

1. 系统无法启动；
2. 系统文件损坏（常伴随输入/输出错误提示）；
3. 外接存储设备（包括 U 盘或 SD 卡）工作异常。

2.fsck 命令格式与选项详解

运行 fsck 需具备超级用户权限（root），该命令支持多种参数，具体使用需根据实际情况选择。

2.1 基本命令格式

fsck [选项] [文件系统]

2.2 常用选项

（1）检查范围控制

（2）文件系统类型筛选

（3）交互模式与自动修复

（4）设备与操作控制

（5）高级与特殊选项

2.3 fsck 退出代码的含义

fsck运行后会返回退出代码，可通过man fsck命令查看代码说明：

代码含义对照表：

4.检查根分区的两种方法

由于无法在已挂载状态下检查根分区，可通过以下两种方式操作：

方法一：强制下次启动时执行fsck

只需在根目录创建特定文件即可：

touch /forcefsck

随后重启系统，下次启动时将自动执行fsck。请注意：如果系统存在大量inode，检查可能耗时较长，生产环境应合理安排维护窗口。

重启后检查该文件是否仍存在，为避免每次启动都执行检查，建议完成后删除该文件：

ls /forcefsck

方法二：在救援模式下运行 fsck

（1）重启前停止在主机上已运行的服务，然后执行重启命令：

reboot

（2）紧接着设置并进入紧急救援模式：

GRUB 菜单操作：
1）选择"CentOS Linux 7"
2）按【e】编辑
3）在 linux16 行尾添加：systemd.unit=rescue.target
4）按【Ctrl+X】启动
5）输入 root 密码，进入紧急救援模式

（3）执行 fsck 修复

# 1 切换到安全位置
cd /run/initramfs

# 2 查看根分区设备
df -h /
# 通常为：/dev/mapper/centos-root 或 /dev/sda2

# 3 卸载根分区
umount /dev/mapper/centos-root

# 4 执行修复（根据文件系统类型）
# ext4/ext3:
fsck -y /dev/mapper/centos-root
# XFS:
xfs_repair /dev/mapper/centos-root

# 5 重新挂载测试
mount /dev/mapper/centos-root /mnt
ls /mnt

（4）重启验证

# 重启系统
reboot

# 验证修复
journalctl -xb | grep -i fsck
df -h

5.根分区修复实际案例

5.1 问题描述

物理机、虚拟机突然断电，可能造成文件系统损坏。如果文件系统损坏，下次开机时，操作系统将以紧急模式启动，将看到如下提示信息：

You are in emergency mode. After logging in, type “journalctl -xb” to view system logs, “systemctl reboot” to reboot, “systemctl default” or “exit” to boot into default mode. Give root password for maintenance (or press Control-D to continue):

此时，部分分区没有挂载到具体的目录，无法访问其中的文件，需要修复这些分区中的文件系统。

5.2 操作步骤

（1）查看未成功挂载的分区

输入 root 用户的密码并回车，执行lsblk命令，查看未成功挂载的分区。

NAME                  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                     8:0    0  3.3T  0 disk 
├─sda1                  8:1    0    1G  0 part /boot/efi
├─sda2                  8:2    0    1G  0 part /boot
└─sda3                  8:3    0  3.3T  0 part 
  ├─vg_root-esight    253:0    0  3.2T  0 lvm  /opt
  ├─vg_root-var_tmp   253:1    0  4.6G  0 lvm  /var/tmp
  ├─vg_root-tmp       253:2    0 10.2G  0 lvm  /tmp
  ├─vg_root-var_audit 253:3    0    2G  0 lvm
  ├─vg_root-var_log   253:4    0  9.8G  0 lvm
  ├─vg_root-root      253:5    0 20.4G  0 lvm  /
  ├─vg_root-var       253:6    0  4.7G  0 lvm  /var
  ├─vg_root-usr       253:7    0  5.1G  0 lvm  /usr
  ├─vg_root-home      253:8    0    1G  0 lvm  /home
  └─vg_root-swap      253:9    0   32G  0 lvm  [SWAP]

如上所示，查看“MOUNTPOINT”列（该列展示了挂载点），可见“vg_root-var_audit”以及“vg_root-var_log”分区没有挂载点。

（2）修复操作

针对没有挂载的分区，执行如下命令进行修复。不同的分区名称，执行的修复命令如下表所示。

这里为了修复“vg_root-var_audit”中的文件系统，需要执行如下命令：

fsck /dev/vg_root/var_audit

回显如下：

fsck from util-linux 2.35.2
e2fsck 1.45.6 (28-Mar-2028)
/dev/mapper/vg_root-var_audit contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 16 has an inwalid extent node (blk 34385, lblk B)
Clear<y>? y
Inode 16 extent tree (at level 1) could be shorter. Optimize<y>? yes
Inode 16, i_blocks is 16406, should be @. Fix<y>? yes
Pass 1E: 0ptimizing extent trees
Pass 2: Checking directory structure
Pass 3: Checking directory comectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(33031--33847) -33186 -(34848--34303) -34385 -(35328--36863) -(38144--38383) -(38338--38344) -(38784--38847)
Fix<y>? y
Free blocks count wrong for group #1 (23961, counted=26811).
Fix<y>? y
Free blocks count wrong (589138, counted=582675).
Fix<y>? y
Free inodes count wrong (134884, counted=134888).
Fix<y>? y
/dev/mapper/g_root-Mar_audit: xxxxx FILE SYSTEH UhS NUDIFIED xxxx
/dev/mapper/vg_root-var_audit: 167134896 files (25.8% non-contiguous), 32877/535552 blocks

用同样的方法，修复”vg_root-var_log“分区。

（3）重新挂载所有分区

修复完成后，重新挂载：

mount -a

（4）检查修复结果

执行lsblk命令，确认修复结果：

NAME                  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                     8:0    0  3.3T  0 disk 
├─sda1                  8:1    0    1G  0 part /boot/efi
├─sda2                  8:2    0    1G  0 part /boot
└─sda3                  8:3    0  3.3T  0 part 
  ├─vg_root-esight    253:0    0  3.2T  0 lvm  /opt
  ├─vg_root-var_tmp   253:1    0  4.6G  0 lvm  /var/tmp
  ├─vg_root-tmp       253:2    0 10.2G  0 lvm  /tmp
  ├─vg_root-var_audit 253:3    0    2G  0 lvm  /var/log/audit
  ├─vg_root-var_log   253:4    0  9.8G  0 lvm  /var/log
  ├─vg_root-root      253:5    0 20.4G  0 lvm  /
  ├─vg_root-var       253:6    0  4.7G  0 lvm  /var
  ├─vg_root-usr       253:7    0  5.1G  0 lvm  /usr
  ├─vg_root-home      253:8    0    1G  0 lvm  /home
  └─vg_root-swap      253:9    0   32G  0 lvm  [SWAP]

最后重启系统。

以上关于如何使用“fsck”工具修复Linux文件系统错误？的文章就介绍到这了，更多相关内容请搜索码云笔记以前的文章或继续浏览下面的相关文章，希望大家以后多多支持码云笔记。