我的根分区格式化为 ext4 文件系统。
我注意到，每当我的机器崩溃并且我必须对其进行硬重置时，当再次启动并检查根文件系统时，此步骤比从完全关闭的系统启动时花费的时间要长一些（例如一到两秒），但据报道它是“干净的”（并且没有类似的东西/dev/<rootpartition> was not cleanly unmounted, check forced）。文件系统已满 92% (352 GiB)。
我的问题：我想知道这是否是 ext4 的正常且安全的行为，还是启动脚本中的某些错误。我知道 ext4 的 fsck 速度比 ext3 快得多，但我担心系统崩溃后它会被报告为“干净”。
当我e2fsck -f在该分区上手动运行时，检查的持续时间与 ext2/ext3 文件系统相当。所以我很担心，因为我调整了我的文件系统，以便在每次启动时进行检查（tune2fs -c 1），这导致一次完整的检查需要与e2fsck -f每次启动一样长的时间。
编辑，只是为了澄清：在非干净重置之后，通常在 /var（即 reiserfs）上，fsck 会重播日志条目；在 /boot（即 ext2）上，fsck 运行，显示进度条，并在运行后报告“clean”。仅在根文件系统上不会出现“强制检查”并且不会出现 fsck 进度，而对于其他文件系统，即使结果是干净的，也会出现这种情况。这就是令人担忧的差异！
答案1
ext4 是一个日志文件系统，日志的主要目标之一是在不干净的关闭情况下生存而不造成损坏，因此不需要长时间的 fsck。
简而言之，像 ext3/4 这样的日志文件系统会（至少）写入元数据更改两次。首先，它将它们写入“日志”。然后，一旦它位于磁盘上，它就会写入实际的文件系统元数据。 （写入日志要快得多，因为日志是连续的并且不需要大量查找。至少在磁盘上，SSD 上的查找惩罚大大减少。）
额外的几秒钟可能是日志重播：基本上，如果文件系统没有完全卸载，下一次挂载fsck将读取日志并应用主文件系统中尚未存在的任何更改。
简而言之，听起来它的行为符合预期。
答案2
当您的文件系统未完全卸载时（通常是当您必须硬重置时），Fsck 通常在启动时运行。 fsck 将在安装文件系统之前对其进行检查，如果检测到出现问题（不一致、无法重播日志、孤立 inode...），则报告错误；如果未检测到任何错误，则报告“干净”。所以在你的情况下你很幸运并且你的文件系统没问题。如果您想了解有关 fsck 内部工作原理的更多信息，有一篇关于 fsck 的非常有趣的文章：https://lwn.net/Articles/248180/
答案3
已经fsck发生在 initrd/ initramfs 中（在不干净的关闭之后，此阶段需要花费几秒钟的时间，并且有大量磁盘活动，其中日志似乎被重播），因此，当正常的、更详细的文件系统检查正在从主系统运行，它已经干净了。