私たちのアプリケーションは、巨大なリングバッファ（30〜150TB）でディスクにデータを書き込みます。新しいファイルは、古いファイルの削除中に記録されます。したがって、定義によると、ディスクは常に「ほとんどいっぱいです」。
これ作家このプロセスは、約100〜150 Mbits / sの正味入力速度でさまざまなファイルを生成します。データファイルは、1 GBの「データ」ファイルと複数の小さなメタデータファイルが混在しています。 （入力速度は一定ですが、新しいファイルセットは2分ごとに作成されます。）
別の削除者30秒ごとに「最も古い」ファイルを削除するプロセスです。ディスクの空き容量が15 GBに達するまで削除され続けます。
したがって、安定して実行されると、すべてのデータパーティションの空き容量は15 GBしかありません。
存在するこの問題ファイルシステムの速度低下に関して憂鬱なダニエルコメントしました：
同期の中断は、単にファイルシステムが最新の操作を一貫して保存するのに苦労していることを意味します。その時点で、ディスク上のデータを移動しようとします。詳細はわかりませんが、ファイルシステムが真剣に断片化されている場合は、ext4がこれに対処することを確信しています。ファイルシステムがほぼ100％いっぱいになると悪いです。 100％に近い容量でファイルシステムを利用する唯一の合理的な方法は、一部のファイルで静的に初期化してから同じファイルを上書きすることです（断片化を防ぐため）。おそらくext2/3に最適です。
ext4はこのアプリケーションに適していない選択ですか？これでリアルタイムで実行されているので、断片化、速度低下、またはその他のパフォーマンス制限を防ぐためにext4をどのように調整できますか？ ext4で変更するのは非常に難しいでしょう...
（静的に生成されたファイルを再構築することは、アプリケーション全体を再構築することを意味します）
ありがとうございます！
私を編集する
サーバーには50〜100 TBのディスク（24台のドライブ）が接続されています。 Areca RAIDコントローラは、24台のドライブをRAID-6 RAIDセットとして管理します。
そこで、それぞれ5TBから10TBの範囲の複数のパーティション/ボリュームに分割されました。したがって、ロールのサイズはそれほど大きくはありません。
「作成者」プロセスは、「十分な」スペースを持つ最初のボリュームを見つけ、そこにファイルを書き込みます。ファイルが作成されたら、プロセスを繰り返します。
新しいシステムでは、ボリュームが順次充填されます。すべてのボリュームが「いっぱい」になると、「十分な」スペースが利用可能になるまで、「プログラムの削除」プロセスは最も古いファイルの削除を開始します。
時間が経つにつれて、他のプロセスの操作により、ファイルの時系列順がすべてのボリュームにランダムに分散されます。
編集2
ランはfsck1〜2％の非常に低い断片化を示しています。しかし、同時に遅いファイルシステムへのアクセスは、他のさまざまなシステムコールのために実行に時間がかかることを追跡しましたfclose()（fwrite()5〜60ftello()秒！）。
これまで、この問題に対する解決策はありません。詳細については、この問題を参照してください。非常に遅い（200秒）fwrite（）/ftello（）/ fclose（）をデバッグする方法は？
無効にsysstatし、raid-check改善があることを確認しました。
ベストアンサー1
原則として、リングバッファの書き込みを厳密にすると断片化に問題が発生する理由がわかりません。簡単なようです。私の考えでは、この説明はより一般的な書き込み作業量に基づく推奨事項です。しかし、リンクされた質問を見ると本当の問題があるようです...
断片化に興味があるので、それを測定する方法を検討する必要があります！ e4defrag存在する。 2つのオプションしかありません。 -c現在の状態のみが表示され、デフラグは実行されません。 -v各ファイルの統計を表示します。すべてのオプションの組み合わせが有効です（オプションなしを含む）。実行中のシステムに対するパフォーマンスの影響を制限する明示的な方法はありませんが、e4defrag個々のファイルに対する実行をサポートしているため、直接速度を制限できます。
（XFSにもデフラグツールがありますが、私は試したことがありません。）
e2freefrag空き領域の断片化を表示できます。 もしCFQ IOスケジューラを使用している場合は、低いIO優先順位で実行できますionice。
引用された推測は間違っており、Stephen Jeterの答えは正確でした。 ext4 は自動デフラグを実行しません。記録されたデータを「シャッフル」しようとしません。
この奇妙な誤解を放棄すると、「ext2 / ext3」を提案する理由はありません。それ以外の場合、現在カーネルにext3コードがありません。 ext4 コードは ext3 をマウントするために使用されます。 ext3 は ext4 のサブセットです。特に比較的大きなファイルを生成する場合、範囲を使用しないことは愚かなように見えます。これはext4に固有の機能です。
私は「絞首刑」がジャーナリングとより頻繁に関連していると思います。 （ファイルシステムの進行中）の説明を参照してください。bcachefs-
テールレイテンシは長年にわたりext4ユーザーの悩みでした。ロギングコードや他の場所の依存関係により、マルチスレッドワークロードでの単純な操作（切断）などの30秒以上の遅延が発生する可能性があります。誰も問題を解決する方法がわからないようです。
bcachefsがIOでスレッドをブロックする唯一の理由は、スレッドがそれを明示的に要求した場合（キャッシュされていない読み取りまたはfsync操作）、またはリソースが使い果たされた場合（完全停止）です。 IO の実行中にフォアグラウンド操作をブロックするロックは維持されません。 bcachefsはまだリアルタイムファイルシステムではありませんが（IOのリアルタイム予約機能が不足しています）、いつかリアルタイムファイルシステムになる可能性があります。
XFSを使用して上記の問題をどの程度回避できるかを説明するように依頼しないでください。わかりません。ただし、代替ファイルシステムの設定テストを検討している場合は、XFSが私が試す最初の設定です。
ext4でロギングを無効にすると、どのような影響があるかについて多くの情報を見つけようとしています。少なくともパフォーマンスをチューニングするときに考慮される一般的なオプションの1つではないようです。
なぜsys_sync（）を使うのかわかりません。一般的に避けるのが最善です（例：ここ）。これが実際にあなたの問題を説明しているかどうかはわかりませんが、範囲を狭くしようとしている間に発生した不幸なようです。