常にフル稼働するようにext4を最適化する
私たちのアプリケーションは、巨大なリングバッファ（30〜150TB）としてデータをディスクに書き込みます。古いファイルを削除しながら新しいファイルを書き込む。そのため、定義上、ディスクは常に「ほぼ満杯」です。
writerプロセスは、約100〜150 Mbits/sの正味入力速度でさまざまなファイルを作成します。データファイルは、1GBの「データ」ファイルといくつかの小さなメタデータファイルの混合物です。 （入力速度は一定ですが、新しいファイルセットは2分に1回だけ作成されることに注意してください）。
30秒ごとに「最も古い」ファイルを削除する個別のdeleterプロセスがあります。ディスクの15GBの空き容量に達するまで、削除を続けます。
したがって、安定した動作では、すべてのデータパーティションに15GBの空き領域しかありません。
this SO question ファイルシステムの速度低下に関連して、 DepressedDaniel コメント：
同期のハングは、ファイルシステムが最新の操作を一貫して保存するために懸命に働いていることを意味します。その間、ディスク上のデータをシャッフルしようとしていることは間違いありません。詳細はわかりませんが、ファイルシステムが大幅に断片化されている場合、ext4はそれについて何かをしようとします。そして、ファイルシステムがほぼ100％いっぱいになっている場合、それは良くありません。容量のほぼ100％でファイルシステムを利用する唯一の合理的な方法は、いくつかのファイルで静的に初期化してから、同じファイルをその場で上書きすることです（断片化を避けるため）。おそらくext2/3で最適に動作します。
Ext4はこのアプリケーションにとって悪い選択ですか？ライブで実行しているので、断片化、速度低下、またはその他のパフォーマンス制限を回避するために、ext4に対してどのような調整を行うことができますか？ ext4からの変更は非常に難しいでしょう...
（静的に作成されたファイルを書き換えることは、アプリケーション全体を書き換えることを意味します）
ありがとう！
編集I
サーバーには50から100のTBのディスクが接続されています（24ドライブ）。ArecaRAIDコントローラーは24台のドライブをRAID-6RAIDセットとして管理します。
そこから、いくつかのパーティション/ボリュームに分割します。各ボリュームは5〜10TBです。したがって、1つのボリュームのサイズは大きくありません。
「ライター」プロセスは、「十分な」スペースを持つ最初のボリュームを見つけて、そこにファイルを書き込みます。ファイルが書き込まれた後、プロセスが繰り返されます。
新品のマシンの場合、ボリュームは順番にいっぱいになります。すべてのボリュームが「いっぱい」の場合、「削除者」プロセスは、「十分な」スペースが使用可能になるまで、最も古いファイルの削除を開始します。
長い間、他のプロセスのアクションのために、ファイルの時系列はすべてのボリュームにランダムに分散されます。
編集II
fsckを実行すると、断片化が非常に少なくなります：1〜2％。ただし、その間、ファイルシステムへのアクセスが遅いのは、fclose()、fwrite()、ftello()などのさまざまなシステムコールの実行に非常に長い時間がかかるためです（5 60秒まで！）。
これまでのところ、この問題の解決策はありません。詳細については、こちらをご覧くださいSO質問： 非常に遅い（200秒）デバッグ方法）fwrite（）/ ftello（）/ fclose（）？
sysstatとraid-checkを無効にして、改善があるかどうかを確認しました。
原則として、厳密なリングバッファ書き込みが断片化に関して問題を引き起こす理由はわかりません。簡単そうです。この引用は、より一般的な書き込みワークロードからのアドバイスに基づいているように思えます。しかし、リンクされたSOの質問を見ると、実際に問題があることがわかります...
断片化が心配なので、それを測定する方法を検討する必要があります！ e4defragが存在します。 2つのオプションしかありません。 -cは現在の状態のみを表示し、デフラグは行いません。 -vはファイルごとの統計を示します。オプションのすべての組み合わせが有効です（オプションなしを含む）。実行中のシステムへのパフォーマンスへの影響を制限する明示的な方法は提供されていませんが、e4defragは個々のファイルでの実行をサポートしているため、自分でレート制限できます。
（XFSにはデフラグツールもありますが、使用したことはありません。）
e2freefrag空き領域の断片化を示すことができます。 CFQ IOスケジューラーを使用する場合、を削減して実行できますIO ioniceを使用した優先度。
引用は間違っていると推測し、スティーブン・キットによる回答は正しい。 ext4は自動デフラグを実行しません。すでに書き込まれているデータを「シャッフル」しようとはしません。
この奇妙な誤解を捨てても、「ext2/ext3」を提案する理由はありません。他のものとは別に、ext3コードは現在のカーネルには存在しません。 ext4コードは、ext3をマウントするために使用されます。 ext3はext4のサブセットです。特に、比較的大きなファイルを作成している場合、エクステントを使用しないのはばかげているように見えます。これらはext4固有の機能です。
「ぶら下がっている」ことは、ジャーナルに関連していることが多いと思います。たとえば、 （進行中のファイルシステム）からのコメント bcachefs -
テールレイテンシーは長年ext4ユーザーの悩みの種でした-ジャーナリングコードや他の場所での依存関係は、マルチスレッドワークロードでの単純な操作（リンク解除など）で30秒以上のレイテンシーにつながる可能性があります。誰もそれらを修正する方法を知らないようです。
Bcachefsでは、スレッドがIOでブロックする唯一の理由は、明示的に要求されたため（キャッシュされていない読み取りまたはfsync操作）、またはリソースの枯渇-完全停止です。フォアグラウンド操作をブロックするロックは今日、bcachefsはリアルタイムファイルシステムではありませんが（たとえば、IOのリアルタイムスケジューリングが不足しています）、おそらく1日になる可能性があります。
XFSを使用することで上記の問題をどの程度回避できるかを解釈するように私に頼まないでください。知りません。ただし、別のファイルシステムセットアップのテストを検討している場合は、XFSを最初に試します。
Ext4でジャーナリングを無効にした場合の影響に関する多くの情報を見つけるのに苦労しています。少なくとも、パフォーマンスを調整するときに考慮される一般的なオプションの1つではないようです。
なぜsys_sync（）を使用しているのかわかりません。通常は避ける方がよいでしょう（例： ここ を参照）。それがあなたの問題を本当に説明しているのかどうかはわかりませんが、これを絞り込もうとすると不幸なことに遭遇するようです。
これは別のアプローチですが、多少複雑です。
多くの小さなパーティションを作成します。たとえば、そのうちの10個または20個を作成します。 LVM2 このシナリオで役立つ場合があります。次に、次のようにリングバッファ方式でパーティションを使用します。
パーティションの1つは常に「アクティブ」なパーティションであり、完全にいっぱいになるかほぼいっぱいになるまで新しいデータが書き込まれます。ヘッドルームを残す必要はありません。アクティブなパーティションがいっぱいになった場合、またはデータの次のチャンクを保持するのに十分な空き領域がない場合は、次のパーティションに切り替えて、アクティブなパーティションにします。
削除プロセスでは、完全に空のパーティションが少なくとも1つ使用可能であることを常に確認します。存在しない場合（これが重要な部分です）、最も古いパーティションを単純に再フォーマットして、新しいファイルシステムを作成します。この新しいパーティションは、後で断片化を最小限に抑えて、またはまったくなく、新しいデータを受信できるようになります。