fsck必须在文件系统未挂载时运行，否则易致数据永久丢失；默认只读检查，需加-y或-r等参数才修复；修复后须重新挂载并验证功能，且优先排查smart等硬件问题。
linux文件系统损坏时，fsck是唯一能直接修复元数据的工具，但它的安全使用有明确前提：必须在未挂载状态下运行。误在读写挂载中执行，极大概率导致数据永久丢失或目录结构崩溃。
确认分区是否已卸载
运行 fsck 前，务必验证目标设备未被挂载。常用方法：
- 用
mount | grep /dev/sdX1或lsblk -f查看挂载状态 - 若已挂载，先执行
umount /dev/sdX1 - 若提示 target is busy，用
lsof +D /mount/point或fuser -v /mount/point找出并终止占用进程 - 根分区（如
/）无法在线卸载，需从 Live USB 或 systemd emergency 模式启动后操作
选对参数才能真正修复
默认运行 fsck /dev/sdX1 仅做只读检查，发现错误也不会修正——这是最常被忽略的风险点。
- 预检不改动：
fsck -n /dev/sdX1（推荐首次使用） - 自动修复所有可判定错误：
fsck -y /dev/sdX1 - 交互式修复（适合关键数据区）：
fsck -r /dev/sdX1 - 更稳妥的做法是直接调用专用工具，例如：
e2fsck -y /dev/sdX1（ext4）、xfs_repair /dev/sdX1（xfs）
修复后必须验证可用性
fsck 完成不等于文件系统已恢复正常。日志可能未重放、inode 可能被清空、挂载选项也可能失效。
- 手动重新挂载：
mount /dev/sdX1 /mnt - 立即测试基础功能：
ls /mnt、cat /mnt/testfile - 检查关键路径：
ls -la /mnt/home、ls -la /mnt/lost+found（后者应存在且非空） - 若挂载后报 input/output Error 或反复提示 Filesystem has errors，大概率是 SSD 坏块或磁盘物理故障，此时 fsck 无能为力
别跳过硬件健康检查
频繁出现文件系统错误，往往不是软件问题，而是硬件告警。修复前建议快速筛查底层设备状态：
- 查看 SMART 信息：
sudo smartctl -a /dev/sda - 重点关注 Reallocated_Sector_Ct、Current_Pending_Sector、UDMA_CRC_Error_Count 等字段
- 若显示 failing_now 或阈值临近归零，应立即停止写入，并优先备份数据
- SSD 或 RAID 设备上运行 fsck 前，确认控制器和固件无异常，避免误判为文件系统问题