180日後にfsckするかしないか
デフォルトでは、180日またはいくつかのマウントの後、ほとんどのLinuxファイルシステムはファイルシステムチェック（fsck）を強制します。もちろん、これは、たとえばext2またはext3でtune2fs -c 0 -i 0を使用してオフにすることができます。
小さなファイルシステムでは、このチェックは不便なだけです。ただし、ファイルシステムが大きい場合、このチェックが完了するまでに数時間かかることがあります。ユーザーが生産性をこのファイルシステムに依存している場合、たとえばNFS経由でホームディレクトリにサービスを提供している場合、スケジュールされたファイルシステムチェックを無効にしますか？
現在午前2時15分で、非常に長いfsck（ext3）が完了するのを待っているので、この質問をします！
180日間のデフォルトのfsck時間は、ext3がオンライン整合性チェックをサポートしないという設計上の欠陥の回避策です。本当の解決策は、これをサポートするファイルシステムを見つけることです。成熟したファイルシステムがそうかどうかはわかりません。それは本当の悲劇です。おそらく、btrfsによって1日節約できます。
標準メンテナンスの一環として、完全なfsckを使用してスケジュールされた再起動を行うことにより、fsckからの驚異的な数時間のダウンタイムの問題に対応しました。これは、稼働時間中に小さな破損が発生し、それが実際の停止に変わるよりも優れています。
問題の大きな部分は、ext3のfsckが非常に遅いことです。 xfsの方がfsckははるかに高速ですが、大規模なファイルシステムでは、ディストリビューションがデフォルトでxfsを推奨するにはメモリを使いすぎます。それでも、ほとんどのシステムではこれは問題ではありません。 xfsに切り替えると、少なくともかなり高速なfsckが可能になります。これにより、通常のメンテナンスの一環としてfsckを実行するのが簡単になります。
RedHatを実行していて、xfsの使用を検討している場合、それらがxfsの使用をどれほど強く妨げるか、実行しているカーネルでxfsを使用している人がほとんどいないという事実に注意する必要があります。
私の理解では、ext4プロジェクトの目標はfsckのパフォーマンスを少なくともある程度改善することです。
これは、本番サーバーがすべて単独で実行されるべきではなく、常にホット/コールドバックアップがあるか、2ノードクラスタに参加する必要があるもう1つの理由だと思います。最近の仮想化では、物理メインサーバーと仮想サーバーを簡単に作成できます。仮想サーバーは、X日ごとに実行される物理サーバーのコピーにすぎず、引き継ぐ準備ができています。
それ以外の場合、これはあまり役に立たない答えですが、データの重要性のバランスをとるべきだと思います...これが単なるクラスタノードの場合は、スキップしてください。これがクライアントのバックアップされていないWebサーバーである場合、次回は事前に計画することをお勧めします:-)
Depends ..たとえば、QMailスタックを実行していた定期メンテナンスのために、1台のサーバーを停止させました。 QMailは時間の経過とともに多くのファイルを作成および削除し、非常にビジーなメールサーバーでした。 fsckは約36時間かかりました。それは取引から地獄のような多くのパフォーマンスを救ったようなものではありませんが、最終的にはファイルシステムがより健全であったと主張できると思います。それに続いて起こった混乱の価値は本当にあったのでしょうか？ない。で。すべて。
XFSは興味深いものです。常に一貫したFSです。 fsckは必要ありません。 fsckによるダウンタイムは発生しません。
しかし、別の問題があります。 HDD不良ブロックの処理に対応したRAIDコントローラが必要です。
XFSには、OSが不良ブロックを認識し始め、HDDハードウェアの不良ブロックリストがいっぱいになったときに、不良ブロックをブラックリストに登録する機能がありません。
ext2/3/4、fat、ntfsなど（オフラインテスト）では、不良ブロックをブラックリストに登録できますが、XFSはブラックリストに登録できません。
したがって、エンタープライズ以外のインストールの場合、XFSはおそらくあまり適していません。 XFSをLinuxソフトウェアraid1と共に使用して、コンテンツが時間の経過とともにほとんど変化しない小さなファイルがたくさんあるバックアップパーティションに使用しています。