ext4のディレクトリごとの最大ファイル

私は、すべてのファイルがmd5の合計に等しいファイル名で保存されるファイルストアを含むアプリケーションを管理します。すべてのファイルは1つのディレクトリに保存されます。現在は数千ありますが、すぐにサーバー上の数百万のファイルになります。現在のサーバーは、ext4ファイルシステムでUbuntu 11.10を実行しています。

誰かが私に、ディレクトリに多くのファイルを置くのは賢明ではないと言った、これは検索時間と信頼性の大幅な増加を引き起こすからです（彼は単一のディレクトリが指すことができる最大ファイルについての話を持っていたので、大きなリンクリストになりました）。代わりに、ファイル名のサブストリングなどを使用してサブディレクトリを作成することを提案しました。ただし、これにより、アプリケーションの一部の処理が非常に面倒になります。

これはまだ本当ですか、または現代のファイルシステム（たとえばext4）はこれに対処し、自然にスケーリングするより効率的な方法を持っていますか？ウィキペディアにはファイルシステムに関する詳細がありますが、ディレクトリごとの最大ファイル数や検索時間については何も言及していません。

ext3以降のファイルシステムがサポートしてハッシュされたBツリーのディレクトリインデックスを。これは、追加、削除、および名前によるアクセスのみを行う操作である限り、非常に適切に拡張されます。ただし、ディレクトリを分割することをお勧めします。そうでなければ、あなたはツールのための危険なブービートラップを作成します（updatedb、ls、duなど）のディレクトリがあまりにも多くのエントリがある場合に爆破できるディレクトリに他の操作を実行しています。

問題の中心は、必要な1つのファイルのディレクトリiノードを掘り下げることです。一部のファイルシステムは、他のファイルシステムよりもこれをうまく行います。数十億に近い規模もありますが、もしあなたが...あれば、それらのファイルに到達する 20K ファイルは著しく速くなります。また、ファイル数が多いと特定のツールで問題が発生し、結果としてバックアップ/復元がより困難な問題になる可能性があります。

たまたま、私たち自身の開発でまったく同じ問題に遭遇しました（ファイル名としてのmd5sum、そのスケーリング）。開発者に勧めたのは、文字列を細かく切ることです。彼らは4つのグループで行きましたが、その時点であったファイルシステムでは、多くの人がパフォーマンスの観点から問題があることを証明するので、最初の6つのトリプレットのためにグループ3で分割し、残りを端末ディレクトリ内のファイル名。

グループ4：4976/d70b/180c/6142/c617/d0c8/9d0b/bd2b.txt
グループ3：497/6d7/0b1/80c/614/2c6/17d0c89d0bbd2b.txt

これには、ディレクトリサイズを小さく保つという利点があり、MD5sumはかなりランダムなので、バランスの取れたディレクトリツリーが作成されます。その最後のディレクトリがいくつかのファイルを取得することはまずありません。そして、コードに取り組むのはそれほど難しくありませんでした。私たちは数百万のファイルプロジェクトを扱っているため、スケーリングは非常に重要でした。

最新のファイルシステムは、非常に大きなディレクトリを非常にうまく処理します。しかし、従来のツールにはありません。たとえば、このような大きなディレクトリを「ls」でリストすると、通常はディレクトリ全体を読み取ってソートするため、非常に長い時間がかかります（ソートを回避するにはls -fを使用できます）。すべてが読み取られるまで、ファイルの表示は開始されません。名前の分割はいくつかの場合に役立ちますが、すべてではありません（たとえば、rsyncレプリケーションはまだ名前のツリー全体を収集する必要がある場合があります）。

代わりにSQLデータベースを使用することをお勧めしますか？これにより、アプリケーションで認識されているこの弱点が強みに変わる可能性があります。