fsck是修复文件系统元数据的唯一工具，但必须在卸载状态下运行，否则易致数据丢失；需用mount确认挂载状态，根分区须从Live USB操作；默认只读检查，修复需加-y或-r参数；修复后须重新挂载并验证。
文件系统损坏时，fsck 是唯一能直接干预元数据的工具，但它不能在挂载状态下安全运行——强行操作大概率导致数据彻底丢失。
必须先卸载分区再运行 fsck
绝大多数错误都源于用户在设备仍挂载（尤其是读写挂载）时执行 fsck。系统会拒绝操作，或给出警告 fsck: error 2 (No such file or directory) 或更隐蔽的 filesystem is mounted 提示，但有些版本仍允许继续，结果是索引错乱、目录项消失。
- 用
mount | grep /dev/sdX1确认是否挂载；若已挂载，先执行umount /dev/sdX1 - 根分区无法手动卸载，需从 Live USB 启动后操作；此时设备名可能变化，用
lsblk -f或blkid重新识别目标分区 - 如果
umount报错target is busy，用lsof +D /mount/point或fuser -v /mount/point查看占用进程
fsck 参数选错会导致静默跳过修复
默认不加参数运行 fsck /dev/sdX1 只做只读检查，即使发现错误也不会修正——这是最常被忽略的行为。真正触发修复需要明确指令。
- 自动修复所有可判定错误：
fsck -y /dev/sdX1（-y表示对所有提示回答 yes） - 交互式修复（适合关键分区）：
fsck -r /dev/sdX1，每步停顿等待确认 - 跳过特定类型检查（如不校验块使用状态）：
fsck -c /dev/sdX1（慎用，-c实际调用e2fsck -c检测坏块，非通用参数） - 指定文件系统类型更安全：
fsck.ext4 -y /dev/sdX1，避免fsck自动推断出错
修复后必须重新挂载并验证可用性
修复完成不代表文件系统已恢复一致状态：日志可能未重放、挂载选项可能失效、甚至部分 inode 被清空为 0。直接重启或继续使用有风险。
- 运行
mount /dev/sdX1 /mnt重新挂载，立即测试能否ls /mnt、cat /mnt/testfile - 检查关键目录是否存在且可进入：
ls -la /mnt/home、ls -la /mnt/lost+found（后者应存在且非空，说明修复生效） - 若挂载后出现
Input/output error或反复报ext4 filesystem has errors，说明底层硬件（如 SSD 坏块）可能已损坏，fsck无能为力
真正难处理的不是命令怎么敲，而是判断该不该修、修到哪一步为止——比如 fsck 报出数百个 UNEXPECTED INCONSISTENCY 并自动重建 lost+found 下几十个编号文件，这些文件名早已丢失，内容是否可用只能靠人工抽样验证。
