直接卸载再运行 fsck 是唯一稳妥解法，因“device or Resource busy”表明分区正被占用；需先用 mount、lsof 或 fuser 确认并释放占用，根文件系统须进 rescue 模式或 live cd 操作。
fsck 报错 “Device or resource busy” 怎么办
直接卸载再运行 fsck 是唯一稳妥解法。它报这个错，说明目标分区正被系统或进程占用——比如挂载着、有打开的文件、甚至只是被某个服务锁住了设备节点。
- 先用
mount | grep /dev/sdX1确认是否还挂载着；若挂载，必须先umount /dev/sdX1 - 如果提示“target is busy”，别硬 umount，先用
lsof +D /mount/point或fuser -v /mount/point查谁在用 - 根文件系统无法卸载？只能进 rescue 模式或 Live CD 启动后操作；
systemctl rescue不够用，它仍会挂载 root 为 read-write - 别在运行中的系统上对已挂载的 ext4 分区执行
fsck -y——可能损坏日志，触发强制只读挂载甚至 panic
ext4 下该用 e2fsck 还是 fsck
fsck 只是个调度器，实际干活的是 e2fsck。你敲 fsck -t ext4 /dev/sdX1，底层就是调 e2fsck；但绕过 fsck 直接调 e2fsck 更可控、错误提示更准。
- 优先用
e2fsck -f -y /dev/sdX1：-f 强制检查（跳过“clean flag”判断），-y 自动确认修复 -
fsck在 /etc/fstab 里定义了pass字段（第6列），开机时按此顺序自动调用对应工具；但手动修复时没必要依赖它 - 不要用
fsck.ext4这个别名——它是e2fsck的符号链接，但语义模糊，容易误以为是独立工具 - 注意：e2fsck 对未 clean 卸载的 ext4 日志会先回滚，耗时明显；若只是想看状态，用
e2fsck -n（只读模式）更快
“Superblock checksum does not match” 错误怎么救
这是 ext4 元数据严重损坏的典型信号，不是普通文件损坏，而是超级块校验失败。默认超级块只有一个，但 ext4 在多个位置备份了副本，可以换用备份恢复。
- 先用
dumpe2fs -h /dev/sdX1 2>/dev/NULL | grep -i "superblock"查备份位置（如 32768、98304…） - 用
e2fsck -b 32768 /dev/sdX1指定备份超级块启动修复（替换为你查到的数字） - 如果所有备份都坏，且没开
metadata_csum，可尝试mke2fs -n /dev/sdX1模拟生成新 superblock 结构，再人工比对修复——但这已是数据抢救范畴，不建议自行操作 - 日常预防：确保关机前 sync 完成；SSD 上避免突然断电；定期用
e2fsck -n做只读巡检
xfs_repair 和 e2fsck 的关键区别在哪
XFS 不支持在线修复，也不像 ext4 那样靠超级块备份兜底。它的修复逻辑完全不同：不改原结构，而是重建整个元数据索引，所以必须严格满足前提条件。
- 必须先
umount，且不能有任何进程访问该设备；xfs_repair会拒绝处理已挂载或 open 的设备 - 不接受 -y 参数，所有交互式确认都得手动输 yes；加
-n可预览修复步骤，但不执行 - 若提示 “AG count mismatch”，大概率是底层设备容量变了（如扩容后没通知内核），需先
blockdev --rereadpt /dev/sdX再试 - XFS 没有传统“脏位”概念，所以即使正常关机，
xfs_repair也可能报告需要修复——只要日志没清空，它就认为不一致
文件系统修复不是“跑个命令就完事”的操作。最常被忽略的是：没确认设备是否真正空闲、没区分日志型文件系统的修复前提、把只读检查和写入修复混为一谈。尤其在虚拟机或云盘场景下，底层存储异常可能让 fsck 表面成功，实则掩盖了更深层的 I/O 故障。