fsckはいつ危険ですか？
最近、整合性の問題の結果として、リモートデータセンターのマシンのルートファイルシステムが読み取り専用で再マウントされるのを見ました。
再起動時に、このエラーが表示されました：
UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (i.e., without -a or -p options)
提案どおりにfsckを実行し、修正を手動で受け入れた後 Y、エラーが修正され、システムに問題はなくなりました。
ここで、fsckがすべてを自動的に実行および修復するように構成されていると興味深いと思います。これは、このような場合の唯一の代替策は、リモートデータセンターに直接行って、影響を受けるマシンにコンソールを接続することです。
私の質問は、なぜfsckはデフォルトで手動介入を要求するのですか？そのようなプログラムによって実行される修正がどのように、そしていつ安全でないのでしょうか？システム管理者が提案された修正をしばらくの間（他の操作を実行するために）残したい、またはすべて一緒に中止したい場合はどれですか？
fsckは、基盤となるハードウェアが何らかの形で損傷している場合、間違いなく害をもたらします。 CPU、RAM、ハードディスクドライブ、ディスクコントローラーの不良。
疑わしい場合は、破損したディスクのイメージをdd_rescueまたはその他のツールで取得し、そのイメージを正常に修正できるかどうかを確認することをお勧めします。これにより、元のセットアップを引き続き使用できます。
fsckが機能するoneの例を見ましたが、正常に機能しなかった破損したファイルシステムが十分にあります。すべて。それが完全に自動で機能する場合、ddディスクダンプなどの多くの場合に修復を試みる前に実行する優れたアイデアであるようなものを実行する機会がない可能性があります。
never、everは、自動のようなものをすべて試すことをお勧めします。
ああ、そして現代のサーバーは、リモートコンソールまたは少なくとも、サーバーにKVMラックを持ち込むことなく、そのようなものから回復するための独立したレスキューシステムを備えている必要があります。
まず、最新の（ジャーナル化された）ファイルシステムでは、システムクラッシュによってファイルシステムが破損することはなく、起動時にfsckが必要ないことを理解する必要があります。
Ext3、Ext4、ZFS、btrfs、xfsおよびすべての最新のFSは、クラッシュまたはシステムのリセット後も100％一貫しています。
非ジャーナル化FSは、システムrootfsにとって大きなNOGOです。
さて、あなたのシステムがブート時にfsckを必要とするなら、あなたはあなた自身に尋ねるべきです：そもそもこれの理由は何でしたか？
カーネルログを後で調査して、いつ、何が起こったかを確認する必要があります。また、エラーが発生してから、ログで時間を遡って検索する必要もあります。 smartctlを使用してディスクをチェックする必要があります。など...ジャーナル化されたfsにfsckが必要な場合、fsが管理者（ddのようなブロックレベルのツールを使用）またはバグによって損傷されていないと仮定すると、ハードウェアが故障していることは事実上確かです。
そのため、根本的な原因を調査して修正することなく（障害のあるハードウェア/ファームウェア/ソフトウェアを交換/アップグレードすることにより）、fsckを使用して問題を「修正」するのはばかげています。
Fsckを実行し、ブートを完了して幸せになることは、控えめに言っても世間知らずです。 「私がfsckで作業した時間の割合が、引用したものよりも大きい」と言っていると、「fsckでの作業」の意味がわからなくなります。 fsckは、処理中にいくつかのファイルとデータを失うことにより、fsを一貫した状態に戻した可能性があります...バックアップと比較しましたか？多くの人は、気付かないうちにファイルを失ったり、ファイルのデータが破損したりします...