web-dev-qa-db-ja.com

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

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

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

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

performancefilesystemscontinuous-integrationbuild-server
10
Dan Fabulich

Ext4fsをベースファイルシステムとして使用し、次のようないくつかの高速化オプションを使用します

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

次に、その上にtmpfs ramdiskをユニオンマウントして、ビルド中に書き込まれたファイルがramdiskのメリットを享受できるようにします。ビルド手順を変更して、ビルドの最後に結果のバイナリをtmpfsから移動するか、アンマウントする前にtmpfsをext4fsにマージして戻します。

6
Michael Dillon

最速のファイルシステム？ noatimeが設定された状態で、使用可能なRAMからtmpfsがマウントされました。

これは、ソースツリーの構築に必要なすべてをチェックアウトする手順があり（再起動するとtmpfsファイルシステムの内容がなくなるため）、ソースとオブジェクトが利用可能なRAM（スワップせずにコンパイラとリンカを実行するのに十分な残りがあります）。つまり、RAMでの作業に勝るものはありません。

6
voretaq7

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ノードを提供します。ビルド環境では多くのファイルが作成されるため便利です。

2
insider

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

次の選択肢（私は通常そうします）はReiserであり、Extではありません。 Ext3は最近少し速くなる可能性がありますが、Reiser3にはiノードのフォーマット時間制限がなく、「data =」のオンライン変更をサポートしていますオプション。 「テール」サポートがあり、小さなファイルをより密にパックできますが、速度が気になる場合は「ノーテール」にしてください。

XFSとJFSはどちらも、「小さなファイルがたくさんある」場合、特にそれらをrmする必要がある場合は苦痛になります。

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

0
poige

説明する操作は、理想的なファイルシステムが実行できる必要があることに関するいくつかの重要なヒントを提供します。

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

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

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

各ファイルシステムには、さらにいくつかのパーセンテージポイントを探すために実行できるスピードアップがほとんどありません。基盤となるストレージのパフォーマンスは、表示されるゲインに大きく影響します。

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

0
sysadmin1138

小さなファイルがたくさんある場合は、ext3、xfs、jfs ...よりもReiserをお勧めしますが、このアクセスパターンでは、ext4の方が以前のバージョンよりもはるかに優れている（つまり、poiseの言うこととは逆）と聞いています。

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

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

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

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

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

0
symcbean