fsck修复成功需以输出“FILE SYSTEM WAS MODIFIED”为关键标志（ext系列），XFS则看“done”或“phase 5 complete”；修复后必须重新挂载并验证mount含rw、tune2fs -l显示state为clean且Last checked时间更新，再通过touch/rm测试及dmesg无错误确认。
fsck 执行完后怎么看是否真的修好了
文件系统修复是否成功，不能只看命令有没有报错或“done”，关键得看输出里有没有明确的修改确认和后续状态验证。很多用户跑完 fsck -y /dev/sda1 就以为万事大吉，结果重启后还是只读、丢文件，问题其实没解决。
- 成功最直接的标记是输出中出现
FILE SYSTEM WAS MODIFIED（注意大小写和空格）——这是 e2fsck 系列工具（ext2/3/4）的标准提示，表示有实质改动，不是空跑 - 如果只看到
clean或0 errors corrected，说明没发现问题，也不代表“修复成功”，只是当前无误 - 对 XFS 文件系统，
xfs_repair不会打印 “was modified”，但成功时末尾会有类似done或phase 5 complete；失败则明确报ERROR或卡在某 phase - 修复后必须
umount再mount，否则内核仍用旧缓存；挂载后检查mount | grep /dev/sda1是否含rw（不是ro）
tune2fs -l 输出里哪些字段说明修复已生效
修复完成后，用 tune2fs -l /dev/sda1 查看元数据，重点盯这几个字段：
-
Filesystem state:必须是clean（不是not clean或errors）——这是 ext 系统认为“健康”的核心标志 -
Last checked:时间戳应更新为本次修复执行的时间（不是上次启动时间） -
Revision level:一般不变，但如果修复了 superblock 损坏并从备份恢复，这里可能显示1 (dynamic)或版本号重置 -
Mount count:和Maximum mount count:配合看：若Mount count归零或重置，说明 fsck 清除了脏标记
为什么 df -h 显示正常不代表修复成功
df -h 只反映空间使用情况，完全不体现文件系统结构一致性。常见陷阱：
- 修复中途被中断（比如电源掉电），
df仍能显示容量，但ls /mnt报Input/output error - superblock 损坏后用备份恢复，
df正常，但部分 inode 丢失，find /mnt -inum 12345直接失败 - 修复未清空
/lost+found，里面堆满#123456文件，说明大量目录项断裂，df看不出异常 - XFS 修复后
df正常，但应用写入时报Stale file handle，需检查dmesg | grep xfs是否有 replay 失败日志
真正可靠的验证动作只有两个
别信输出文字，动手验证才靠谱：
- 创建并删除一个文件：
touch /mnt/test && sync && rm /mnt/test，不报错且ls /mnt/test返回非零才稳 - 检查内核日志是否有新错误：
dmesg -T | tail -20 | grep -i "ext4\|xfs\|error\|fail"，修复后应无相关报错
最容易被忽略的是：修复完成必须重启或至少重新挂载，否则内核仍按损坏前的缓存运行。哪怕 fsck 输出再漂亮，没这步，等于没修。
