必须在未挂载或只读状态下运行fsck，否则极易导致数据永久损坏；普通分区需先umount再fsck，根分区须进单用户模式或Live环境，修复前应空跑预览、只读检查、交互式修复，并按文件系统类型选用e2fsck、xfs_repair等专用工具。
不能直接在挂载状态下运行 fsck 修复，否则大概率导致数据永久损坏——这是最核心的底线，不是建议，是强制前提。
fsck 必须在未挂载或只读状态下执行
一旦分区已挂载（mount 状态），fsck 会拒绝操作或静默破坏元数据。常见错误现象包括：
fsck: /dev/sdb1 is mounted; will not check- 修复后文件系统无法再次挂载，或
/LOST+FOUND突然暴增大量#XXXXXX文件 - 修复完成重启后系统卡在 initramfs 提示符
实操要点：
- 普通分区：先
sudo umount /dev/sdxx，再运行fsck - 根分区（
/）：必须进单用户模式（如 GRUB 启动时按e编辑内核参数，追加rd.break或init=/bin/bash）或使用 Live CD/USB - LVM 逻辑卷：卸载前确认 LV 已停用，例如
sudo lvchange -an /dev/vg_name/lv_name - 如果
umount报错“device busy”，用lsof +D /mount/point或fuser -v /mount/point查进程并终止
别盲目用 -a 或 -y 自动修复
-a 和 -y 会跳过所有人工确认，对严重损坏（如超级块损坏、inode 链断裂）可能直接清空节点或覆盖关键结构，导致文件不可逆丢失。
安全做法是分三步走：
- 先空跑预览：
sudo fsck -N /dev/sdxx，看它打算修什么 - 再只读检查：
sudo fsck -n /dev/sdxx（-n表示只读，不写磁盘） - 最后交互式修复：
sudo fsck /dev/sdxx（不带自动参数），遇到y/n提示时逐条判断
特别注意：当提示 The superblock could not be read 或 UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY，说明已有元数据级损坏，此时 -y 极其危险。
不同文件系统要用对应底层工具
fsck 只是个调度器，真正干活的是 e2fsck（ext2/3/4）、xfs_repair（XFS）、dosfsck（FAT）等。硬套 fsck -t xfs 会失败，因为 XFS 不支持原地修复，必须用专用命令。
常见匹配关系：
- ext4 分区 → 实际调用
e2fsck，可直接运行sudo e2fsck -f /dev/sdxx - XFS 分区 → 必须用
sudo xfs_repair /dev/sdxx，且要求该分区已卸载、无脏日志（必要时加-L清日志，但会丢未提交事务） - FAT32/U盘 → 用
sudo fsck.vfat -a /dev/sdxx，避免用通用fsck调用出错 - 若不确定类型，先查：
sudo blkid /dev/sdxx或lsblk -f
修复后挂载失败？检查返回值和日志
fsck 执行完不等于万事大吉。它的退出码才是关键信号：
-
0：干净，无错误 -
1或2：有错误且已修复 → 正常，可尝试mount -
4：有错误但未修复 → 挂载大概率失败，需重试或换策略 -
8：运行时出错（如 I/O 错误）→ 很可能是硬盘物理故障，先smartctl -a /dev/sda检查 SMART
修复过程日志默认不保存，但可手动记录：sudo fsck -V -C /dev/sdxx 2>&1 | tee /tmp/fsck-$(date +%s).log。重点盯 FILE SYSTEM WAS MODIFIED 是否出现，没这句说明根本没修成功。
真正麻烦的从来不是命令怎么敲，而是修到一半发现超级块全坏、或 lost+found 里全是零长度文件——这时候得切到 e2fsck -b 8193 尝试备用超级块，或者放弃修复，直接上 testdisk 或 photorec 救数据。
