必须先卸载ext4分区再运行fsck修复逻辑损坏，否则易致数据丢失；使用df -h或lsblk确认挂载状态，umount后执行fsck -y自动修复，修复后需验证clean状态并只读测试再读写挂载。
不能直接在已挂载的EXT4文件系统上运行 fsck 修复逻辑损坏，否则极易导致数据彻底丢失。必须先卸载（umount）目标分区，再执行检查与修复。
确认目标分区并确保已卸载
使用 df -h 或 lsblk 查看挂载状态，找到待修复的设备（如 /dev/sdb1）。若该分区正被挂载（例如挂载在 /mnt/data），需先执行：
-
sudo umount /dev/sdb1（推荐用设备名卸载，避免路径误判） - 若提示“target is busy”，可用
sudo lsof +D /mnt/data查看占用进程，或重启进入恢复模式 - 根文件系统（
/）无法在线卸载，需从Live USB启动后操作
执行基础检查（只读预览）
首次操作建议先只读扫描，确认问题类型和严重程度：
-
sudo fsck -N /dev/sdb1：显示将要执行的操作（不实际运行） -
sudo fsck -v /dev/sdb1：详细输出检查过程，但不自动修复 - 观察输出中是否出现“inode X has invalid mode”、“directory Y has bad block”等提示，判断是否为典型逻辑错误（非硬件坏道）
安全修复逻辑错误
确认无硬件故障后，执行自动修复（仍需人工确认关键操作）：
-
sudo fsck -y /dev/sdb1：对所有可安全修复的问题自动回答“yes”（适合常见逻辑错误） -
sudo fsck -C /dev/sdb1：显示进度条，适合大分区 - 若遇到“UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY”错误，说明超级块异常，可尝试指定备份超级块：
sudo dumpe2fs -h /dev/sdb1 | grep -i "superblock"→ 找到备份位置（如32768），再运行sudo e2fsck -b 32768 /dev/sdb1
修复后验证与挂载
修复完成后不要立即使用，应验证一致性并谨慎挂载：
- 再次运行
sudo fsck -v /dev/sdb1，确认输出为“/dev/sdb1: clean, XXX/YYY files, AAA/BBB blocks” - 临时以只读方式挂载测试：
sudo mount -o ro /dev/sdb1 /mnt/test，检查关键文件能否正常访问 - 确认无误后，再以读写方式挂载：
sudo mount /dev/sdb1 /mnt/data - 建议随后运行
sudo touch /mnt/data/.fsck_repaired并记录时间，便于后续追踪
