必须用blkid /dev/sdxy确认文件系统类型，因其直接读取设备元数据，比df -t更可靠；ext4用e2fsck，xfs必须用xfs_repair，不可混用。
怎么确认当前分区用的是哪种文件系统
不先搞清类型就乱跑修复命令，轻则报错退出，重则把XFS当ext4修、直接丢数据。最稳妥的方式是查设备本身，不是看挂载点或猜。
用 blkid /dev/sda1 最直接：它会输出类似 /dev/sda1: UUID="..." TYPE="ext4" 或 TYPE="xfs" 的结果。如果没装 blkid（极少见），可用 lsblk -f 或 file -s /dev/sda1 替代。
注意别依赖 df -T：它显示的是挂载后的类型，但若分区已损坏无法挂载，df 就压根列不出该设备；而 blkid 读的是设备头部元数据，只要物理层可读就能识别。
ext2/ext3/ext4 该用哪个命令修复
统一用 e2fsck，不是 fsck —— 后者只是个分发器，实际调用的还是 e2fsck。但很多人误以为 fsck 是通用工具，结果在XFS上硬跑 fsck -y /dev/sdb1，提示 “fsck from util-linux 2.39” 后直接报错退出，浪费时间还误判问题。
e2fsck 的关键选项：
-
-n：只读检查，看有哪些错误但不动文件系统，适合首次诊断 -
-y：自动修复所有可修复项，适合已知问题简单、且无重要未备份数据时使用 -
-f：强制检查，绕过“clean”标记，某些异常关机后文件系统可能被错误地标记为 clean -
-c：检测并标记坏块（对机械盘有用，SSD慎用）
示例：e2fsck -fn /dev/sdb1 先看问题，确认后再跑 e2fsck -fy /dev/sdb1。
XFS 文件系统不能用 fsck，必须用 xfs_repair
这是最容易踩的坑：fsck 对 XFS 分区完全无效，连模拟检查都不支持。强行运行只会输出 “fsck: error 2 while executing fsck.xfs for /dev/sdb1”，或者干脆静默失败。
xfs_repair 的行为和 e2fsck 有本质区别：
- 它不要求分区提前卸载（但强烈建议卸载），可尝试在只读挂载状态下运行
- 不支持
-y这类自动确认选项，所有修复都是确定性的，无需交互 -
-L选项会强制清空日志，丢失未提交的写操作——仅在xfs_repair报 “cannot initialize log” 等严重元数据错误时才考虑，且必须接受数据丢失风险
安全流程：先 xfs_repair -n /dev/sdb1 检查，再 xfs_repair /dev/sdb1 修复。别跳过 -n 阶段。
其他文件系统对应工具不能混用
Btrfs、ReiserFS、NTFS 等都有专属工具，不存在“一个 fsck 走天下”的情况：
- Btrfs：用
btrfs check --repair /dev/sdb1，但官方明确警告--repair是高危操作，生产环境应优先用btrfs check /dev/sdb1只读诊断 - ReiserFS：用
fsck.reiserfs，严重损坏时可能需--rebuild-tree，耗时极长 - NTFS：用
ntfsfix /dev/sdb1，它不处理复杂损坏，只是清理日志并设为“需要 Windows chkdsk”
真正麻烦的是 LVM 逻辑卷或加密卷（如 LUKS）：得先激活卷组（vgscan && vgchange -ay）或解密设备（cryptsetup open），再对内部的 /dev/mapper/vg-lv 设备运行对应工具。漏掉这步，工具根本找不到目标设备。
