単一ディレクトリ内のファイルシステムの多数のファイル

それほど大きくはありませんが、平均サイズが30kbの約60,000個のファイルが単一のディレクトリに格納されているものを使用する必要があります（これは要件であるため、ファイル数の少ないサブディレクトリに単純に侵入することはできません）。

ファイルはランダムにアクセスされますが、作成されると同じファイルシステムへの書き込みはありません。現在Ext3を使用していますが、非常に遅いと感じています。助言がありますか？

XFSを検討する必要があります。ファイルシステムとディレクトリレベルの両方で非常に多くのファイルをサポートし、B +ツリーデータ構造のために多数のエントリがあっても、パフォーマンスは比較的安定しています。

Wikiには、デザインの詳細を示す多数の論文や出版物のページがあります。試してみて、現在のソリューションに対してベンチマークを行うことをお勧めします。

Linuxで10億個のファイル

この記事の著者は、ファイル数が多いファイルシステムのパフォーマンスの問題を掘り下げ、ext3、ext4、およびXFSのさまざまなファイルシステムのパフォーマンスをうまく比較しています。これはスライドショーとして利用できます。http://events.linuxfoundation.org/slides/2010/linuxcon2010_wheeler.pdf

ext3のディレクトリにある多くのファイルについては、姉妹サイトstackoverflow.comで詳細に議論されています。

私の意見では、ext3の1つのディレクトリにある60 000個のファイルは理想からはほど遠いですが、他の要件によっては十分かもしれません。

OK。ReiserFS、XFS、JFS、Ext3（dir_hashが有効）およびExt4dev（2.6.26カーネル）を使用していくつかの予備テストを行いました。私の第一印象は、すべてが十分に高速だったということでした（私の強力なワークステーションで）-リモートの実稼働マシンのプロセッサはかなり遅いことがわかりました。

最初のテストでもReiserFSで奇妙なことを経験したので、それを除外しました。JFSのCPU要件は他のすべてのものより33％少ないため、リモートサーバーでテストします。十分に機能する場合は、それを使用します。

私はもっ​​とたくさんのファイルを保存するアプリケーションを書いていますが、私のものはもっと大きく、1000万のファイルがあり、複数のディレクトリに分割します。

ext3は、主にデフォルトの「リンクリスト」実装のために低速です。そのため、1つのディレクトリに多数のファイルがある場合、別のディレクトリを開いたり作成したりする速度はますます遅くなります。ext3で利用可能なhtreeインデックスと呼ばれるものがあり、これにより状況が大幅に改善されると報告されています。ただし、ファイルシステムの作成時にのみ使用できます。こちらをご覧ください：http : //lonesysadmin.net/2007/08/17/use-dir_index-for-your-new-ext3-filesystems/

とにかくファイルシステムを再構築する必要があるので、ext3の制限のため、ext4（またはXFS）の使用を検討することをお勧めします。ext4はファイルが小さいほど少し速く、再構築も速くなると思います。私の知る限り、ext4ではHtreeインデックスがデフォルトです。私は実際にJFSやReiserの経験はありませんが、以前にそれを勧められたと聞いたことがあります。

実際には、おそらくいくつかのファイルシステムをテストするでしょう。ext4、xfs、jfsを試して、どれが全体的なパフォーマンスが最高になるかを見てみませんか？

開発者がアプリケーションコードの処理を高速化できると私に言ったことは、「stat + open」呼び出しではなく、「open + fstat」を実行することです。1つ目は2つ目よりもかなり遅いです。あなたがそれに対して何らかのコントロールや影響を持っているかどうかはわかりません。

stackoverflowに関する私の投稿を参照してください。 Linux で最大1,000万個のファイルを保存およびアクセスするには、非常に役立つ回答とリンクがいくつかあります。

tune2fsを使用してdir_indexを有効にすると役立つ場合があります。有効になっているかどうかを確認するには：

sudo tune2fs -l /dev/sda1 | grep dir_index

有効になっていない場合：

sudo umount /dev/sda1   
sudo tune2fs -O dir_index /dev/sad1
sudo e2fsck -D /dev/sda1
sudo mount /dev/sda1

しかし、私はあなたが間違った道を進んでいるかもしれないと感じています...フラットインデックスを生成し、それに基づいていくつかのコードを使用してランダムに選択しないのはなぜですか？その後、サブディレクトリを使用して、より最適化されたツリー構造を作成できます。

ext3以下は、ディレクトリごとに最大32768個のファイルをサポートします。ext4は、実際のファイル数で最大65536をサポートしますが、さらに多くのファイルを保持できます（ほとんどのユーザーの目的には関係ありません）。

また、ext *ファイルシステムにディレクトリを保存する方法は、本質的に1つの大きなリストです。最新のファイルシステム（Reiser、XFS、JFS）では、それらはBツリーとして保存されます。これは、大規模なセットに対してはるかに効率的です。

ファイル名の代わりにファイルiノードを保存できます。iノード番号へのアクセスは、ファイル名を解決するよりもはるかに高速です。

1つのディレクトリにそのような多くのファイルを詰め込みたくはなく、何らかの構造が必要です。ファイルの最初の文字で始まるサブディレクトリを持っているような単純なものであっても、アクセス時間を改善できます。私が使用したい別の愚かなトリックは、システムにキャッシュをメタ情報で強制的に更新させることです。updatedbを定期的に実行します。1つのウィンドウでslabtopを実行し、別のウィンドウでupdatedbを実行すると、キャッシュに多くのメモリが割り当てられることがわかります。この方法ははるかに高速です。

これらのファイルでデータの種類を指定しませんでした。しかし、その音から、クイック検索のためにインデックス付きのある種のデータベースを使用する必要があります。

ファイルシステムは、おそらくこのような要件には理想的なストレージではありません。何らかの種類のデータベースストレージが優れています。それでも解決できない場合は、ファイルをいくつかのディレクトリに分割し、unionfsを使用して、すべてのファイルを表示する単一のディレクトリにそれらのディレクトリをマウント（バインド）します。私はこの手法をまったくスピードアップに使用していませんが、試してみる価値はあります。