总有些时侯，文件系统不能正常 umount. 比如死机，比如没有电池的笔记本或者没有 UPS 供电的台式机遭遇停电。出现这种情况，启动脚本会在下次做 fsck 操作。但对于热插拔的 U 盘，一般不会在 /etc/fstab 中有相关纪录，也就不会在下次挂载时做 fsck. 我的 USB 设备不使用任何自动挂载工具，每次都是手动挂载。如果 U 盘上次没有正常 umount, 那么下次 mount 时系统日志里就会提示: recovery complete, 然后接着顺利挂载。
这句 “recovery complete” 是否意味着 mount 命令自带 fsck 功能？如果是，它的 fsck 效果能跟单独的 fsck 相比吗？我的文件系统是 ext4, 不知道其他文件系统是否会提示 recovery complete, 是否必须运行额外的 fsck.
不是。
很多现代文件系统都可以从异常卸载中自动恢复，btrfs 甚至没有 fsck 工具、异常卸载后全靠日志自行恢复。
因为这些文件系统都像数据库那样有日志，未正常卸载也就可能丢点没来得及写好的数据，不会伤及文件系统自身，不需要全面检查了。对 ext3/4 来说，定期 fsck 有助于提前发现文件系统的损坏以便及时修复。对于 btrfs 来说，这样的全面检查是挂载之后才进行的操作（btrfs scrub），因此没有 fsck。对于 fat 来说，没有任何保护机制，因此未正常卸载时文件系统可能是坏的，需要专门的工具来检查并修复。
需要注意的是，fsck 修的是文件系统自身，不含你的文件数据。因此在文件系统已损坏的情况下，它可能会通过丢弃数据来达成文件系统的一致性（也就是对于需要挽救数据的人来说是「越修越坏」）。
总结：btrfs、ext4、xfs 都不需要主动运行 fsck，而 fat 需要。
谢谢您的耐心解答，不过我发现对于 fsck.ext4 来说，似乎并非全面检查。除非格式化时或者用 tune2fs 设置了定期全面检查，那么对未正常 umount 的 ext4 文件系统运行一下 fsck, 只需一两秒钟，简单提示 succeed to recover journal（原话忘了，大意如此）。只是它的提示信息跟未经 fsck 而直接用 mount 挂载显示的 recovery complete 不一样，让我感觉文件系统的恢复日志跟 fsck 的恢复方法有点不一样。
再次感谢您的解答。
嗯，ext4 的 fsck 优化过了，不像 ext3 的那样需要很久了。