6

プロジェクトにキャッシングを実装中です。キャッシュ ディレクトリ構造を見た後、次のような多くの例を見てきました。

cache
cache/a
cache/a/a/
cache/a/...
cache/a/z
cache/...
cache/z
...

あなたはアイデアを得る。ファイルを保存する別の例として、ファイルの名前がIMG_PARTY.JPGであるとします。一般的な方法は、次の名前のディレクトリに保存することです。

files/i/m/IMG_PARTY.JPG

いくつかの考えが頭に浮かびますが、その本当の理由を知りたいです。

  • 線形ルックアップを行うファイルシステムは、ディレクトリ内のファイル数が少ないほど、ファイルをより速く見つけます。このような構造は、ファイルを薄く広げます。

  • rm有限個の引数を取り、多数のファイルを一度に削除するような *nix ユーティリティを台無しにしないようにするには、ハッキーになる傾向があります (それを渡さなければならないfindなど)。

本当の理由は何ですか？「良い」キャッシュディレクトリ構造とは何ですか?またその理由は何ですか?

4

3 に答える 3

3

私がそれを行うたびに、ファイルシステムでの遅い線形検索を回避することができました。幸いなことに、少なくとも Linux では、これは過去のものになりつつあります。

しかし、今日でも、b-tree ベースのディレクトリでは、すべてのファイルのリストを取得するだけで永遠に 1 日かかるため、非常に大きなディレクトリを扱うのは困難です。

于 2009-03-05T19:01:46.787 に答える
2

日付を使用するだけです。日付で削除しますので。:)

于 2009-03-05T21:07:29.823 に答える
2

その場合、詳細を取得ls -lするためにすべてのファイルを編集する必要がありstat()、これによりリスト時間が大幅に増加します。これは、FS がハッシュ構造または線形構造を使用するかどうかに関係なく発生します。

そのため、FS が信じられないほど大きなディレクトリ サイズに対応できる場合でも、大きなフラットな構造を持たない正当な理由があります (バックアップする豚でもあります)。

ディレクトリ内またはツリー構造に配置された 32,000 個のファイルを使用して GFS2 (クラスター化) のベンチマークを実行しました。ディレクトリのリスト)

EXT4 も同様の比率を示しましたが、エンドポイントはほんの数秒だったので、ほとんどの人は気付かないでしょう。

于 2011-02-10T02:31:15.780 に答える