fsck 必须在卸载文件系统后运行，否则会因保护机制中止；手动执行仅在启动卡住、挂载报错或文件读取异常时才需介入，且须按文件系统类型选用对应工具（如 e2fsck 或 xfs_repair）。
fsck 不能在已挂载的文件系统上安全运行，强行执行可能导致数据损坏。必须先卸载目标分区（umount），或在系统启动早期由 initramfs 自动触发，否则看到 fsck: Cannot continue, aborting 或直接跳过检查都是正常保护行为。
什么时候该手动运行 fsck
不是每次重启都要跑 fsck。现代 ext4/xfs 文件系统默认启用日志（journal），异常断电后通常能自行恢复一致性。手动干预只在以下明确信号出现时才需要：
- 系统启动卡在
fsck阶段，反复提示*** FILE SYSTEM WAS MODIFIED ***或要求按Ctrl+D跳过 - 挂载时报错：
mount: wrong fs type, bad option, bad superblock，且dmesg | tail显示ext4_abort或Superblock checksum does not match - 文件内容读取乱码、
ls报Input/output error、stat返回Stale file handle
如何正确调用 fsck 检查指定分区
先确认设备路径和文件系统类型（lsblk -f 或 blkid），再选择对应工具。不要无脑用 fsck 命令本身——它只是调度器，实际执行的是 fsck.ext4、fsck.xfs 等子程序：
- 对 ext2/ext3/ext4 分区：
sudo e2fsck -f -y /dev/sdb1（-f强制检查，-y自动确认所有修复） - 对 xfs 分区：
sudo xfs_repair /dev/sdb1（xfs_repair不接受-y，需加-L清空日志，但会丢失未写入数据） - 避免使用
fsck -y /dev/sdb1：它可能调用错误的检查器，尤其当分区是 xfs 却匹配到 ext 工具时会报Invalid argument
常见错误与绕不过去的坑
很多问题源于混淆“检查”和“修复”，或忽略底层硬件状态：
-
e2fsck: Bad magic number in super-block：超级块损坏。尝试用备份超级块恢复：e2fsck -b 32768 /dev/sdb1（ext4 默认每 128MB 一个备份，位置可用dumpe2fs -h /dev/sdb1 | grep "Backup superblock"查） -
xfs_repair: cannot initialize XFS library：没装xfsprogs包（Ubuntu/Debian 运行sudo apt install xfsprogs） - SSD 上频繁掉电后
fsck反复失败：可能是 NAND 闪存物理坏块，smartctl -a /dev/sda查看Reallocated_Sector_Ct和Media_Wearout_Indicator
sudo umount /dev/sdb1 sudo e2fsck -f -y /dev/sdb1 sudo mount /dev/sdb1 /mnt/data
真正危险的不是 fsck 本身，而是以为它万能——它修不了硬盘固件故障、RAID 成员盘离线、或加密层密钥丢失。遇到反复报错，先停手，备份裸设备（dd if=/dev/sdb1 of=backup.img bs=4M），再分析。
