解決策 1:
180 日のデフォルトの fsck 時間は、ext3 がオンライン整合性チェックをサポートしないという設計上の欠陥に対する回避策です。本当の解決策は、これをサポートするファイルシステムを見つけることです。成熟したファイルシステムがあるかどうかはわかりません。それは本当の悲劇です。おそらく、btrfs が私たちを救ってくれる日が来るでしょう。
標準メンテナンスの一環として、完全な fsck を使用してスケジュールされた再起動を行うことで、fsck からの予期しない数時間のダウンタイムの問題に対応しました。これは、運用時間中に小さな破損が発生して、実際に停止するよりはましです。
問題の大部分は、ext3 の fsck が不当に遅いことです。 xfs はより高速な fsck を備えていますが、大規模なファイルシステムでデフォルトで xfs を奨励するには、ディストリビューションに大量のメモリを使用します。それでも、ほとんどのシステムではこれは問題になりません。 xfs に切り替えると、少なくともかなり高速な fsck が可能になります。これにより、通常のメンテナンスの一環として fsck を実行するスケジュールが立てやすくなります。
RedHat を実行していて xfs の使用を検討している場合は、RedHat が xfs の使用をどれだけ強く思いとどまらせているか、また実行中のカーネルで xfs を使用している人はおそらくほとんどいないという事実に注意する必要があります。
私の理解では、ext4 プロジェクトには fsck のパフォーマンスを少なくともいくらか改善するという目標があります。
解決策 2:
これは、運用サーバーを単独で実行してはならず、常にホット/コールド バックアップを保持するか、2 ノード クラスターに参加させるべきではないもう 1 つの理由であると言えます。最近の仮想化では、物理メイン サーバーと仮想サーバーを簡単に作成できます。仮想サーバーは X 日ごとに実行される物理サーバーのコピーにすぎず、引き継ぐ準備ができています。
それ以外の場合、これはあまり役に立たない回答です。データの重要性のバランスをとる必要があると思います...これが単なるクラスターノードである場合は、スキップしてください。これがクライアントのバックアップされていない Web サーバーである場合は、次回の計画を立てることをお勧めします :-)
解決策 3:
依存..たとえば、QMail スタックを実行していた 1 台のサーバーを定期メンテナンスのためにダウンさせました。 QMail は、時間の経過とともに大量のファイルを作成および削除し、非常にビジーなメール サーバーでした。 fsck には約 36 時間かかりました。取り引きから大幅に多くのパフォーマンスを節約できたわけではありませんが、最終的には、ファイルシステムがより健全であると主張できると思います.しかし、その後の混乱は本当に価値がありましたか?いいえ。で。すべて。