硬重置后 ext4 被 fsck 报告为干净：这正常吗？

Question

我的根分区被格式化为 ext4 文件系统。

我注意到，每当我的机器崩溃并且我必须对其进行硬重置时，当再次启动并检查根文件系统时，此步骤比从完全关闭的系统启动时花费的时间长一些（例如一到两秒），但它被报告为“干净”（而不是像/dev/<rootpartition> was not cleanly unmounted, check forced）。文件系统已满 92% (352 GiB)。

我的问题：我想知道这是 ext4 的正常和安全行为还是启动脚本中的某些错误。我知道 ext4 的 fsck 比 ext3 快得多，但我担心它在系统崩溃后被报告为“干净”。

当我e2fsck -f在该分区上手动运行时，检查持续时间与 ext2/ext3 文件系统相当。所以我很担心，并且因为 beeing 所以我调整了我的文件系统以在每次启动时进行检查 ( tune2fs -c 1)，这导致每次启动时都需要进行全面检查e2fsck -f。

编辑，只是为了澄清：在非干净重置后，通常，在 /var，即 reiserfs，fsck 重放日志条目；在/boot，也就是ext2，fsck运行，显示进度条，运行后报“clean”。只有在根文件系统上没有“强制检查”并且没有 fsck-progress 出现，其他文件系统也会出现，即使它们是干净的。这就是令人担忧的差异！

Answer 1

ext4 是一个日志文件系统，日志的主要目标之一是在没有损坏的情况下在不干净的关闭中幸存下来，因此不需要很长的 fsck。

简而言之，像 ext3/4 这样的日志文件系统写入元数据（至少）两次更改。首先，它将它们写入“日志”。然后，一旦它在磁盘上，它就会写入实际的文件系统元数据。（写入日志要快得多，因为日志是连续的，不需要一堆查找。至少在磁盘上——SSD 上的查找惩罚大大减少。）

额外的几秒钟可能是日志重放：基本上，如果文件系统没有完全卸载，下一次安装或fsck将读取日志并应用尚未在主文件系统中的任何更改。

所以，简而言之，听起来它的行为符合预期。

Answer 2

已经fsck发生在 initrd/ initramfs 中（在不干净的关闭之后，此阶段需要花费几秒钟的时间，并且有大量磁盘活动，其中日志似乎被重播），因此，当正常的、更详细的文件系统检查正在从主系统运行，它已经干净了。