fsck不能在挂载状态下运行，必须先卸载、检查磁盘健康并用fsck -n只读预检；e2fsck比fsck更可靠，支持备用superblock和坏块扫描；根分区需用live usb操作；修复后挂载失败应立即检查smart数据并做镜像。

fsck 不能在挂载状态下运行，否则大概率导致数据永久损坏；修复前必须卸载、检查磁盘健康、优先用只读预检，否则容易把能救的数据变彻底丢失。

fsck -n 预检为什么不能跳过

很多人看到报错就直接 fsck -y 上，结果修完连 / 都挂不上。因为 fsck 默认行为是只读检查——它不改任何东西，只告诉你“哪里坏了”。这步跳过等于闭眼开刀。

• fsck -n /dev/sda1 会列出所有 inode 损坏、目录链接断裂、孤儿文件等，但不写入磁盘
• 若输出里有 UNEXPECTED INCONSISTENCY 或大量 free inodes count wrong，说明问题真实存在
• 若输出只有 *** FILE SYSTEM WAS MODIFIED *** 且无错误行，说明文件系统其实干净，强行修复反而可能触发 journal 冲突
• SSD 上尤其要谨慎：-n 不触发写入，避免加速坏块扩散

e2fsck -fy 和 fsck -fy 有什么区别

当你明确知道是 ext4 分区时，e2fsck 比 fsck 更可靠。因为 fsck 只是个调度器，它根据 /etc/fstab 或自动探测调用后端工具；而 e2fsck 是 ext 系列专用引擎，参数更细、容错更强。

• fsck -fy /dev/sda1：依赖系统自动识别类型，若 fstab 里写错 ext3 实际是 ext4，可能调用旧版工具出错
• e2fsck -fy /dev/sda1：强制走 ext4 路径，支持 -E journal=journal-path 等高级选项
• 遇到超级块损坏时，e2fsck -b 32768 /dev/sda1 可指定备用 superblock；fsck 不支持该参数，必须显式调用 e2fsck
• e2fsck -c 能直接扫描坏块并加入坏块表；fsck 没这个能力

根分区 / 无法 umount 怎么办

根文件系统不可能在线 umount，硬执行会报 target is busy 并失败。必须切换到外部环境操作。

• 最常用的是 Live USB（如 Ubuntu Live、SystemRescueCD），启动后打开终端，先 lsblk -f 确认根分区设备名（比如 /dev/nvme0n1p2）
• 然后 sudo e2fsck -fy /dev/nvme0n1p2 ——注意不是挂载点路径（如 /mnt），是设备节点
• 若用 systemd 系统且有物理访问权限，可重启进 systemd.unit=emergency.target，此时根分区以只读方式挂载，需先 mount -o remount,rw / 再 umount /，但成功率低，不推荐
• LVM 卷要先激活：sudo vgscan && sudo vgchange -ay，再查逻辑卷名：sudo lvs，最后对 /dev/VolGroup/lv_root 执行检查

修复后 mount 失败或报 Input/output error 怎么办

fsck 返回 0 并不意味文件系统可用。很多情况下元数据已修复，但底层硬件问题暴露出来，这时继续操作只会扩大损伤。

• 立即停手，不要再写入任何数据
• 运行 sudo smartctl -a /dev/sda，重点看 Reallocated_Sector_Ct（重映射扇区数）和 Current_Pending_Sector（等待重映射扇区）——只要这两项非零，就是物理故障
• 若确认是硬盘问题，用 ddrescue -d -r3 /dev/sda /backup/sda.img /backup/sda.log 先做镜像，所有后续操作都在镜像上进行
• 如果 ls /lost+found 为空或报错，说明 inode 表严重损坏，photorec 比 testdisk 更适合抢救单个文件
• 修复后首次挂载务必加 -o ro 只读测试：sudo mount -o ro /dev/sda1 /mnt，确认 ls /mnt 能列出内容再尝试读写

真正麻烦的从来不是 fsck 命令本身，而是它背后暴露的硬件亚健康、LVM 层异常、journal 日志覆盖 superblock 这些隐形问题。每次运行前多花两分钟看 smartctl 和 lsblk，比修三次都管用。