Linux
fsck 什麼時候危險？
最近，由於一致性問題，我看到遠端數據中心中機器的根文件系統以只讀方式重新安裝。
重新啟動時，顯示此錯誤：
UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (i.e., without -a or -p options)按照建議執行 fsck 並使用 手動接受更正後
Y，錯誤已得到更正，系統現在正常。現在，我認為如果將 fsck 配置為自動執行和修復所有內容會很有趣，因為在某些情況下（例如這種情況）唯一的選擇是親自前往遠端數據中心並將控制台連接到受影響的機器。
**我的問題是：為什麼 fsck 預設要求手動干預？**此類程序執行的更正如何以及何時不安全？在哪些情況下，系統管理員可能希望將建議的更正擱置一段時間（以執行一些其他操作）或一起中止它？
fsck如果底層硬體以某種方式損壞，肯定弊大於利；CPU壞，RAM壞，硬碟快要死了，磁碟控制器壞了……在這些情況下，更多的損壞是不可避免的。
dd_rescue如果有疑問，最好使用或其他工具對損壞的磁碟進行映像，然後查看是否可以成功修復該映像。這樣，您仍然可以使用原始設置。
您已經看到了一個有效的範例
fsck，但我已經看到了足夠多的損壞的文件系統，它根本無法成功執行。如果它可以全自動執行，那麼您可能沒有機會執行dd磁碟轉儲之類的操作，在許多情況下，在嘗試修復之前這樣做是一個好主意。嘗試這樣的自動操作從來都不是一個好主意**。**
哦，現代伺服器應該有遠端控制台或至少有獨立的救援系統，以便從類似的情況中恢復，而無需將 KVM 機架拖到伺服器上。