開発者ビルドの最速のファイルシステムは何ですか？

私は、継続的インテグレーションビルドサーバーとして機能するLinuxボックスをまとめています。主にJavaのものを構築しますが、この質問はコンパイルされたすべての言語に当てはまると思います。

どのファイルシステムと構成設定を使用する必要がありますか？（たとえば、私はこれに時間をかける必要がないことを知っています！）ビルドサーバーは、小さなファイルの読み取りと書き込み、およびディレクトリのスキャンを行って、変更されたファイルを確認します。

更新：この場合、データの整合性は優先度が低くなります。それは単なるビルドマシンです...最終的なアーティファクトは圧縮され、別の場所にアーカイブされます。ビルドマシンのファイルシステムが破損してすべてのデータが失われた場合は、ワイプしてイメージを再作成するだけです。ビルドは以前と同様に実行され続けます。

ext4fsを基本ファイルシステムとして使用し、以下のようないくつかの高速化オプションを使用します。

noatime,data=writeback,nobh,barrier=0,commit=300

次に、その上にtmpfs ramdiskをunionマウントして、ビルド中に書き込まれたファイルがramdiskの利点を活用できるようにします。ビルド手順を変更して、ビルドの最後に結果のバイナリをtmpfsから移動するか、マウント解除する前にtmpfsをext4fsにマージします。

最速のファイルシステム？tmpfsは、使用可能なRAMからnoatimeセットでマウントされます。

これは、ソースツリーを構築するために必要なすべてをチェックアウトする手順がある場合にのみ有効です（tmpfsファイルシステムの内容は、再起動すると消えます）。また、ソースとオブジェクトが使用可能なRAMの適切な隅に収まる場合（スワップせずにコンパイラとリンカーを実行するのに十分な残りがあります）。とはいえ、速度を上げるためにRAMの負荷を軽減することはできません

Michael Dillonの答えに、いくつかのオプションでext4ファイルシステムを作成できることを付け加えます。

mkfs.ext4 -O dir_index,extent -i 8096 /dev/<disk>


dir_index
    Use hashed b-trees to speed up lookups in large directories.

extent 
    Instead of using the indirect block scheme for storing the location of data blocks in an inode, use extents instead.  This is a  much  more  efficient  encoding  which  speeds  up filesystem access, especially for large files.

-i 8096は、サイズごとのiノード数を増やします。これは、ビルド環境が多くのファイルを作成するため便利です。

ソースの場合、Reiser4またはBtrfsである圧縮オンザフライサポートを使用することをお勧めします。どちらもまだ「プロダクション用」ではありませんが、両方のFSを多用して楽しく使用していると聞いています。:-)

次の選択（私は通常行う）は、Ext3ではなくReiser3です。現在、Ext3は少し高速になっていますが、Reiser3にはiノードのフォーマット時間制限がなく、「data =」オプションのオンライン変更をサポートしています。それはよりタイトな小さなファイルのパッキングを可能にする「テール」サポートを持っていますが、スピードが気になるなら、それを「通知」してください。

XFSとJFSはどちらも、「大量の小さなファイル」の場合、特にそれらをrm化する必要がある場合には厄介です。

（EXT4について言及するのを忘れた：ええ、それはEXT3よりもさらに高速です。しかし、上記のEXT3の制限はすべてEXT4にもあります）。

あなたが説明する操作は、理想的なファイルシステムが何を実行する必要があるかについていくつかの重要なヒントを与えます：

• ビルドプロセス中の非常にランダムなr / wアクセス。
• 多くのファイルが短時間で更新されるため、高速なメタデータ操作が重要です。
• 非常にファイルが重いファイルシステムで、多くの小さなファイルを効率的に処理します。
• まれで不明瞭なエッジケースでデータ損失のリスクを負わないよう十分成熟しています。

BtrfsとExt4は上記の3つであり、4番目は疑わしいものです。Ext4はおそらくそのために十分成熟していますが、btrfsはまだベイク処理が行われていません。noatimeはメタデータ操作をより効率的にするのに役立ちますが、新しいファイルの束を作成しているときでも、メタデータ操作を非常に高速にする必要があります。

そのとき、基盤となるストレージが要因になり始めます。XFSメタデータ操作は数ブロックに集中する傾向があり、操作に負担をかける可能性があります。Extスタイルのファイルシステムは、メタデータをそれが記述しているデータに近づけることについてより優れています。ただし、ストレージが十分に抽象的である（VPSで実行されている、またはSANに接続されている）場合は、それほど重要ではありません。

各ファイルシステムには、さらに数パーセントのポイントを調べるために実行できる高速化はほとんどありません。基盤となるストレージのパフォーマンスは、表示されるゲインに大きく影響します。

ストレージ用語では、ストレージに十分なI / O操作オーバーヘッドがある場合、ファイルシステムの非効率性はそれほど問題になり始めます。ビルドパーティションにSSDを使用する場合、ファイルシステムの選択は、操作しやすいものほど重要ではありません。

小さなファイルがたくさんある場合、ext3、xfs、jfsよりもReiserをお勧めします。ただし、ext4は、このアクセスパターンの以前の化身よりもはるかに優れている（つまり、落ち着いているとは反対です）と聞きました。

Reiserは多くのファイル構造をiノードツリーまで押し上げます。そのため、小さなファイルを処理する場合に非常にうまく機能します。

ただし、主要なファイルシステム間の動作の違いは、効果的にキャッシュ/バッファリングするのに十分な物理メモリを使用することで得られる利点に比べて比較的小さいものです。

また、ディレクトリをスキャンして、変更されたファイルを確認します。

これは問題を解決するためのくだらない方法です-比較的単純ですが。それが重要な場合は、modにインデックスを付けるためのinotifyハンドラーの作成を検討してください。

OTOH、フラッシュSSDを使用している場合（シーク時間が非常に短くなります）寿命の理由から書き込みをより効果的に分散するfsを使用することをお勧めします（例：JFFS2）