最近,我看到由于一致性问题,远程数据中心中的计算机的根文件系统被重新安装为只读。
重新启动时,显示此错误:
UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (ie, without -a or -p options)
按照build议运行fsck后,用Y手动接受修正,错误得到纠正,系统现在正常。
现在,我认为如果fsck被configuration为自动运行并修复所有内容,这将是一件有趣的事情,因为在某些情况下(比如这个)唯一的select是亲自到远程数据中心,并将控制台连接到受影响的机器。
我的问题是:为什么默认fsck要求手动干预? 如何以及何时由这样的程序进行更正将是不安全的? 当系统pipe理员可能想在一段时间内抛开build议的修正(执行一些其他操作)或将其全部中止时,有哪些情况?
如果底层硬件受到某种程度的破坏, fsck
肯定会造成更多的伤害; 坏的CPU,糟糕的内存,死硬盘,磁盘控制器坏了…在这些情况下,更多的腐败是不可避免的。
如果有疑问,用dd_rescue
或其他工具拍摄损坏的磁盘的图像是一个好主意,然后看看是否可以成功修复该图像。 这样你仍然有可用的原始设置。
你已经看到了一个 fsck
工作的例子,但是我已经看到了更多的损坏的文件系统,在这个文件系统中,它并没有成功。 如果它可以完全自动运行,那么你可能没有办法像dd
盘转储或类似的东西,在尝试修复之前在很多情况下是一个很好的主意。
尝试类似自动化的东西永远不是一个好主意。
哦,现代服务器应该有远程控制台或者至less有独立的救援系统来恢复类似的东西,而不会把KVM机架拖到服务器上。