6

我正在为我的项目实施缓存。查看缓存目录结构后,我看到了许多示例,例如:

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

你明白了。另一个存储文件的例子,假设我们的文件名为IMG_PARTY.JPG,一种常见的方法是将它放在一个名为的目录中:

files/i/m/IMG_PARTY.JPG

一些想法浮现在脑海中,但我想知道真正的原因。

  • 当目录中的文件较少时,执行线性查找的文件系统会更快地找到文件。这种结构将文件分散得很薄。

  • 为了不搞乱 *nix 等实用程序rm,它接受有限数量的参数并一次删除大量文件往往是 hacky(必须通过它find等等)

真正的原因是什么?什么是“好的”缓存目录结构,为什么?

4

3 回答 3

3

每次我这样做时,都是为了避免在文件系统中进行缓慢的线性搜索。幸运的是,至少在 Linux 上,这已成为过去。

然而,即使在今天,使用基于 b-tree 的目录,一个非常大的目录也很难处理,因为要获得所有文件的列表需要永远和一天的时间,更不用说找到正确的文件了。

于 2009-03-05T19:01:46.787 回答
2

只需使用日期。因为您将按日期删除。:)

于 2009-03-05T21:07:29.823 回答
2

如果这样做ls -l,则需要stat()编辑所有文件以获取详细信息,这会大大增加列出时间 - 无论 FS 使用散列结构还是线性结构,都会发生这种情况。

因此,即使 FS 有能力处理非常大的目录大小,也有充分的理由不使用大型扁平结构(它们也是要备份的猪)

我已经在一个目录中或以树结构排列的 32,000 个文件对 GFS2(集群)进行了基准测试 - 递归列表比在平面结构中获取列表快大约 300 倍(可能需要长达 10 分钟才能获得目录列表)

EXT4 显示了类似的比率,但由于终点只有几秒钟,大多数人不会注意到。

于 2011-02-10T02:31:15.780 回答