fsckはいつ危険ですか？

最近、一貫性の問題の結果として、リモートデータセンターにあるマシンのルートファイルシステムが読み取り専用で再マウントされるのを見ました。

再起動時に、次のエラーが表示されました。

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

提案どおりにfsckを実行しY、で手動で修正を受け入れた後、エラーは修正され、システムは正常になりました。

ここで、fsckがすべてを自動的に実行および修復するように構成されている場合、興味深いのは、場合によっては（このような）唯一の代替手段がリモートデータセンターに直接行き、影響を受けるマシンにコンソールを接続することだからです。

私の質問は、なぜfsckがデフォルトで手動の介入を要求するのですか？そのようなプログラムによって実行された修正がいつどのように安全でないのでしょうか？システム管理者が提案された修正をしばらくの間（他の操作を実行するために）残したい場合と、まとめて中止したい場合はどちらですか？

fsck基盤となるハードウェアが何らかの形で破損している場合、間違いなく良いよりも害が大きくなります。悪いCPU、悪いRAM、死にかけているハードドライブ、ディスクコントローラーが悪くなった...これらの場合、より多くの破損が避けられません。

疑わしい場合は、破損したディスクのイメージをdd_rescue他のツールで取得し、そのイメージを正常に修正できるかどうかを確認することをお勧めします。そうすれば、元のセットアップを利用できます。

動作する例を1つ見fsckてきましたが、正常に動作しないファイルシステムが十分に破損しているのを見てきました。完全に自動で動作する場合、ddディスクダンプや、多くの場合、修復を試みる前に行うことをお勧めします。

それはだ決して、これまでまったくその自動ような何かをしようとするのは良いアイデア。

ああ、最近のサーバーには、リモートコンソールまたは少なくとも独立したレスキューシステムがあり、KVMラックをサーバーに接続することなく、そのようなものから回復する必要があります。

まず、最新の（ジャーナライズされた）ファイルシステムでは、システムクラッシュがファイルシステムを破壊せず、ブート時にfsckが必要ないことを理解する必要があります。

クラッシュまたはシステムのリセット後、Ext3、Ext4、ZFS、btrfs、xfs、およびすべての最新のFSは100％一貫しています。

ext2やvfatのような非ジャーナルFSは、システムrootfsにとって大きなNOGOです。

さて、システムがブート時にfsckを必要とするなら、あなた自身に尋ねるべきです：そもそもこの理由は何でしたか？

その後、カーネルログを調べて、いつ、何が起こったかを確認する必要があります。また、エラーがいつ始まったのかを見つけるために、ログをさかのぼる必要があります。smartctlでディスクを確認する必要があります。など...ジャーナル化されたfsでfsckが必要な場合、fsが管理者（ddなどのブロックレベルのツールを使用）またはバグによって破損していないと仮定すると、ハードウェアに障害が発生していることはほぼ確実です。

そのため、根本的な原因を調査して修正することなく（障害のあるハードウェア/ファームウェア/ソフトウェアを交換/アップグレードすることなく）fsckを使用して問題を「修正」するのはばかげています。

fsckを実行し、ブートを完了し、幸せであることは控えめに言っても素朴です。「私はfsckの仕事にあなたが引用したものよりも多くの時間を費やしました」と述べることは、あなたが「fsckの仕事」とはどういう意味か疑問に思います。fsckは、プロセス中のいくつかのファイルとデータを失うことにより、fsを一貫した状態に戻した可能性があります...バックアップと比較しましたか？多くの人が気付かないでファイルを失ったり、ファイルのデータ破損を起こしたりします...