必须先卸载再运行fsck，因挂载时内核缓存元数据，fsck可能误修未刷盘的合法变更，破坏一致性；root分区需进recovery模式或live环境操作。
fsck 不能在已挂载的文件系统上安全运行，尤其是 root 分区；强行执行可能让问题更糟，甚至导致数据丢失。
为什么必须先卸载再运行 fsck
文件系统在挂载状态下，内核持续缓存元数据（如 inode、块位图），fsck 看到的可能是过期或不一致的状态。它修复的“错误”其实是内核还没刷盘的合法变更，结果反而破坏一致性。
- 非 root 分区（如
/dev/sdb1）：用sudo umount /dev/sdb1卸载后再跑fsck - root 分区（如
/dev/sda1）：无法在线卸载，必须进 recovery 模式或 Live CD 环境 - 误对挂载分区执行
fsck，常见报错是busy device或直接跳过检查
fsck -p 和 fsck -a 的区别与风险
两者都尝试自动修复，但行为不同：-p 是“预设安全模式”，只修明确无害的错误（如空闲块计数偏差）；-a 更激进，可能重写部分元数据，旧版工具中甚至会跳过确认直接清空损坏 inode。
- 日常修复优先用
sudo fsck -p /dev/sdc1，它失败时会退出并提示手动介入 -
-a在某些发行版（如老 RHEL）里已被弃用，fsck会静默转为-p - 若
-p报错说 “UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY”，说明有需人工判断的问题，别硬加-y强行覆盖
修复 root 文件系统只能靠启动环境
系统运行时，root 分区必然挂载，fsck 会拒绝操作。你必须中断正常启动流程，进入一个不依赖该分区的独立环境。
- 重启后长按 Shift（BIOS）或 Esc（UEFI）调出 GRUB 菜单
- 选中恢复模式（Recovery Mode）→ 进入菜单后选
fsck项，它会自动 remount root 为只读并执行fsck -p - 若恢复模式不可用，用 Ubuntu/Debian Live USB 启动 → 终端中先
lsblk确认 root 设备（如/dev/nvme0n1p2）→sudo fsck -p /dev/nvme0n1p2 - 注意：Live 环境下不要对
/dev/sr0（光盘）或/dev/loop*（squashfs 镜像）运行fsck，它们不是真实磁盘分区
遇到 superblock 损坏怎么办
ext 类文件系统（ext3/ext4）依赖 superblock 记录全局信息。主 superblock 损坏时，fsck 会报类似 The superblock could not be read 错误，但它通常备份了多个副本。
- 先查备份位置：
sudo dumpe2fs -h /dev/sdc1 2>/dev/null | grep -i superblock - 用备份 superblock 运行：
sudo e2fsck -b 32768 /dev/sdc1（数字替换成上一步查到的备份块号） - 常见备份位置：8193、32768、98304、163840…… 块大小为 1K 时，这些是固定偏移
- 别用
mkfs.ext4重建——那等于格式化，所有数据将丢失
真正麻烦的不是命令怎么敲，而是判断「这个错误能不能自动修」「这块磁盘是不是快坏了」。看到 Bad magic number 或反复出现 Invalid block number，先 smartctl -a /dev/sdX 检硬盘健康，再决定是否继续 fsck。
