最近，我发现由于一致性问题，远程数据中心的一台机器的根文件系统以只读方式重新挂载。
重新启动时，显示以下错误：
UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (i.e., without -a or -p options)
按照建议运行 fsck 并使用 手动接受更正后Y，错误已得到纠正，系统现在正常。
现在，我认为如果将 fsck 配置为自动运行并修复所有内容将会很有趣，因为在某些情况下（例如这种情况）唯一的选择是亲自前往远程数据中心并将控制台连接到受影响的机器。
我的问题是：为什么 fsck 默认要求人工干预？此类程序执行的更正何时以及如何会不安全？在哪些情况下系统管理员可能希望将建议的更正搁置一段时间（以执行其他操作）或完全中止它？
答案1
fsck如果底层硬件以某种方式受损，则肯定会造成更大的危害而不是好处；例如 CPU 坏了、RAM 坏了、硬盘坏了、磁盘控制器坏了……在这些情况下，更多的损坏是不可避免的。
如果有疑问，最好使用dd_rescue或其他工具对损坏的磁盘进行映像处理，然后查看是否可以成功修复该映像。这样，您仍然可以使用原始设置。
答案2
你已看到一示例可以正常fsck工作，但我见过太多损坏的文件系统，它根本无法正常工作。如果它可以完全自动工作，您可能没有机会执行dd磁盘转储之类的操作，而在许多情况下，在尝试修复之前执行这些操作是一个好主意。
它是永远不能尝试这样的自动化装置是一个好主意。
哦，现代服务器应该有远程控制台，或者至少有独立的救援系统，以便从类似情况中恢复，而无需将 KVM 机架拖到服务器上。
答案3
首先，您需要了解，使用现代（日志文件系统）文件系统，系统崩溃不会破坏文件系统，并且在启动时不需要进行 fsck。
Ext3、Ext4、ZFS、btrfs、xfs 和所有现代 FS 在崩溃或系统重置后都是 100% 一致的。
非日志式文件系统 (FS)，例如 ext2 或 vfat，对于系统根文件系统 (rootfs) 来说，是大忌。
现在，如果您的系统在启动时需要 fsck，您应该问自己：首先，这样做的原因是什么？
您应该事后调查内核日志，以查明何时发生以及发生了什么。您还应该回溯日志，以查找错误开始的时间。您应该使用 smartctl 检查磁盘。等等...如果您需要对日志化的 fs 进行 fsck，则几乎可以肯定您的硬件出现故障，前提是 fs 不是由管理员（使用块级工具，如 dd）或错误损坏的。
因此，在没有调查和修复根本原因（通过更换/升级有故障的硬件/固件/软件）的情况下使用 fsck 来“修复”问题是愚蠢的。
执行 fsck、完成启动并感到高兴至少可以说是幼稚的。说“我使用 fsck 的时间比您引用的要长”让我怀疑您所说的“fsck 工作”是什么意思。fsck 可能通过在此过程中丢失一些文件和数据将您的 fs 恢复到一致状态...您是否与备份进行了比较？许多人丢失文件或文件数据损坏却没有注意到...