☰

启动时的 EXT4 FS 检查：声明其干净的条件

tag-icon • tag-icon linux ext4 fsck
启动时的 EXT4 FS 检查：声明其干净的条件

1 个硬盘托管 4 个 EXT4 文件系统，我们将它们命名为 A(1,2,3,4)，每个文件系统都会在我的 fstab 中获得一个条目，但很少安装，驱动器甚至在初始化时通过 udiskctl 关闭电源。

1 个硬盘托管 8 个 EXT4 文件系统，每个文件系统都在我的 fstab 中获得一个条目，其中 4 个，假设 B(1,2,3,4) 在初始化时自动安装，另外四个，假设 C( 1,2,3,4) 偶尔根据需要安装。

在这些情况下（A(1,2,3,4) 未安装且相关驱动器已关闭；C(1,2,3,4) 文件系统中没有一个已安装）并且出于任何原因（电源故障、内核恐慌、硬重置...）系统未正常关闭。
下次重新启动时，将检查每个文件系统。

所有在异常关闭时未安装的文件系统都会很快被清除：

问题一：这个结论是由对超级块的唯一解读得出的吗？s_状态字段或是否进行了其他检查？

Q2：这是否取决于触发异常关闭的原因，是否取决于底层驱动器是否通电？

Q3：这些检查会命令 fsck 挂载文件系统吗？

Q4：虽然控制台上报告了这些干净的状态，但为什么我找不到这些报告在我的内核（或任何其他）日志中回显，而那些实际需要修复并最终从日志中恢复的文件系统的跟踪是？

Linux-5.4/e2fsck 1.46.5/下开放资源库作为初始化系统和元学如果重要的话，充当系统日志守护进程。
Metalog 最相关的规则：

Kernel messages :
        facility        = "kern"
        logdir          = "/var/log/kernel"
        break=1
Fallback:
        facility        = "*"
        minimum         = 6
        logdir          = "/var/log/fallback"

答案1

请不要提出多个问题。

当分区被mount编辑时，文件系统代码将分区的块分配表复制到内存中，并将磁盘的表标记为“需要恢复”。

文件系统代码以内存速度管理块分配，这比磁盘速度快得多。

内存中的表会定期写回磁盘，这样既可以保持它们相对最新，又可以避免将所有表同时保存在内存中。

当分区被umount编辑时，内存中的表被写入磁盘（清除“需要恢复”标志）。内存中的表将被丢弃。

当系统崩溃时，最新的内存表将丢失，并且“需要恢复”标志仍然设置在磁盘上。

如果引导需要文件系统（/etc/fstab条目有auto），并且在磁盘上设置了“需要恢复”标志，则fsck运行特定于文件系统的文件系统（例如，fsck.ext4对于ext4文件系统）来“恢复”文件系统 - 使块分配表“正确” “（最大限度地减少数据丢失，确保没有块既不空闲也不使用，...），保留“需要恢复”时写入的块等。由于正在fsck构建自己的表，因此磁盘可能不会被mount编辑，并且此外，磁盘还设置了“需要恢复”标志，直到fsck成功为止。

这种预安装系统引起的fsck活动发生在引导过程“启动”到足以真正记录消息之前，但请尝试dmesg。

感谢 LustreOne，

在挂载时，e2fsck 将检查日志“需要恢复”标志，并对挂载文件系统所需的超级块和组描述符块进行基本检查。如果设置了“需要恢复”，那么它将重播日志。如果发现其他错误，它将运行文件系统的完整 e2fsck。 – LustreOne

相关内容