fsck 什么时候危险？

Question

最近，由于一致性问题，我看到远程数据中心机器的根文件系统被重新挂载为只读。

重新启动时，显示此错误：

UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (i.e., without -a or -p options)

按照建议运行 fsck 并使用手动接受更正后Y，错误已更正，系统现在正常。

现在，我认为如果将 fsck 配置为自动运行和修复所有内容会很有趣，因为在某些情况下（例如这种情况）唯一的选择是亲自前往远程数据中心并将控制台连接到受影响的机器。

我的问题是：为什么 fsck 默认要求人工干预？此类程序执行的更正如何以及何时不安全？在哪些情况下，系统管理员可能希望将建议的更正搁置一段时间（以执行其他一些操作）或完全中止它？

Answer 1

fsck如果底层硬件以某种方式损坏，肯定会造成弊大于利；CPU坏了，RAM坏了，硬盘坏了，磁盘控制器坏了……在这些情况下，更多的损坏是不可避免的。

如果有疑问，最好使用dd_rescue或其他工具拍摄损坏磁盘的映像，然后查看是否可以成功修复该映像。这样，您仍然可以使用原始设置。

我在硬件故障方面做了很多工作，我同意这一点。如果怀疑有任何类型的坏硬件，我最不想做的就是 fsck。我还看到了自动 fsck 大大延迟的低功耗事件和随后的恢复。 (4认同)
举一个具体的例子：我曾经在一台带有磁盘控制器的机器上工作，该控制器“随机”（大约 10^5 中的 1 次）会将任何设备上对块 XXXXXXYY 的读取或写入转换为对设备上块 000000YY 的写入第一个设备。即，它经常将结构化错误和非结构化错误数据喷射到引导扇区和引导磁盘的各种关键文件系统结构。在这种情况下（数百万次读取）运行 fsck 可以消除恢复数据的任何剩余机会。 (2认同)
10^5 中的 1 个很多……那是 10 个字节，Mb。 (2认同)
@Nelson：有点是......单位是“单块传输”，而不是“字节”。因此，每百万块中有 10 个坏块写入（并且块明显大于字节）。 (2认同)

Answer 2

您已经看到了一个fsck可行的示例，但我看到了更多损坏的文件系统，它根本无法成功运行。如果它可以全自动工作，您可能没有机会执行诸如dd磁盘转储之类的操作，或者在尝试修复之前，在许多情况下这将是一个很好的主意。

这是永远都不会是一个好主意，试图在所有类似的东西自动的。

哦，现代服务器应该有远程控制台，或者至少有独立的救援系统，以便在不将 KVM 机架拖到服务器上的情况下从类似的情况中恢复。

实际上，当事实并非如此时，像这样说“**从不，永远**”并不是一个好主意。一个好主意的用例：如果出现问题，可以相当快地从头开始重新创建服务器的主分区。实际上重要的数据是通过远程文件系统访问的，并为该数据准备了适当的冗余。我更愿意冒险使用 `fsck -p /` 和 `fsck -p /var` 等，工作正常，无需人工干预即可启动服务器，并冒着非零百分比的小概率风险如果需要，我可以重新创建那些分区的灾难。 (7认同)
那需要更长的时间。选项是： A) 风险自动执行。B) 有人告诉 `fsck` 打扮，然后一切正常。如果那样的话，大约需要 2 分钟。停机，直到发生这种情况。C) 找人重新安装操作系统。需要 30+ 分钟。你选C？也许我们的一个关键区别是我让 `fsck` 工作的时间比你在答案中引用的时间要长。我的主要观点不是系统设计（这个便宜的系统不使用远程控制台），而只是说“**从不，永远**”这个词太强了，不准确 (2认同)