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