缓存目录结构

Question

我正在为我的项目实施缓存。看过缓存目录结构后，我看到很多例子：

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，其采取的参数的有限数量和删除大量文件一次趋于哈克（具有通过它虽然find等）

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

Answer 1

每当我做完它，它一直在避免缓慢的文件系统线性搜索。幸运的是，至少在Linux上，这已经成为过去。

但是，即使在今天，如果使用基于b树的目录，一个非常大的目录也很难处理，因为要获取所有文件的清单需要花费很长时间和一天的时间，而不必介意找到正确的文件。

Answer 2

只使用日期。由于您将按日期移除。 :)

Answer 3

如果你做ls -l，所有的文件需要stat()得到的细节，这大大增加了上市时间 - 无论FS使用散列结构还是线性结构，都会发生这种情况。

所以，即使FS具有令人难以置信的大目录大小应对的能力，有很好的理由不要有大的扁平结构（他们也一头猪备份）

我已经基准GFS2 （集群），在一个目录中有32,000个文件或排列成树状结构 - 递归列表的速度比获得列表的速度快300倍，当它们都处于扁平结构时（可能需要10分钟才能获得目录列表）

EXT4显示类似的比率，但因为终点只有几秒钟，大多数人都不会注意到。