男人 e2fsck 说；
请注意，通常在已安装的文件系统上运行 e2fsck 并不安全。唯一的例外是指定了 -n 选项，但未指定 -c、-l 或 -L 选项。然而，即使这样做是安全的，如果安装了文件系统，e2fsck 打印的结果也无效。如果 e2fsck 询问您是否应该检查已安装的文件系统，唯一正确的答案是“否”。只有真正知道自己在做什么的专家才应该考虑以任何其他方式回答这个问题
我可以看到（至少是 ext4）文件系统正在运行错误journalctl -k。表面上，journalctl 获取与 dmesg 实用程序报告相同的内核消息。 fsck 在每个文件系统上的工作方式不同，但通常会检查实际的 fs 日志，在每个 inode (iirc) 上查找其他一些内容。在阅读 man dmesg 时，我看到提到了一个特殊的块设备 /dev/kmsg 和文件 /proc/kmsg。我可以cat /dev/kmsg阅读该信息。这是journalctl -k获取数据的同一来源吗？这与 有何关系e2fsck -n？
答案1
journalctl -k显示日志中来自内核的消息。dmesg显示内核环形缓冲区的内容。两者都显示来自内核的错误，其中包括来自文件系统驱动程序的错误消息；这些是准确的。
这些都不是来自e2fsck.文件系统日志与 . 访问的“日志”无关journalctl。在已安装的文件系统上运行可能会产生不正确的结果，因为文件系统驱动程序维护的数据在运行e2fsck时不一定位于磁盘上，并且在运行时可能会发生变化。e2fscke2fsck
答案2
额外上下文的旁注：在启动期间，一些配置将在根文件系统上systemd运行命令fsck当它以只读方式安装时。根据 中的警告man e2fsck，这并不理想。首选配置是使用 initramfs，它执行正常的操作fsck 前它完全挂载了根文件系统。
（我们有一个现有的问答来解释这一点，但它是一团糟）。
e2fsck -n 在只读安装的文件系统上确实打印有效结果。
e2fsck外部是否-n完全“安全”是另一回事。 （如果不安全，那么也存在结果无效的风险）。我会小心的:-)。但我相信您可以相信，所做systemd的并不比上一代脚本“更不安全”。
我想减少风险，规则是如果fsck必须进行任何更改，系统应立即重新启动。