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