我正在为我的项目实施缓存。查看缓存目录结构后，我看到了许多示例，例如：
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等等）
真正的原因是什么？什么是“好的”缓存目录结构，为什么？
每次我这样做时，都是为了避免在文件系统中进行缓慢的线性搜索。幸运的是，至少在 Linux 上，这已成为过去。
然而，即使在今天，使用基于 b-tree 的目录，一个非常大的目录也很难处理，因为要获得所有文件的列表需要永远和一天的时间，更不用说找到正确的文件了。
只需使用日期。因为您将按日期删除。:)
如果这样做ls -l，则需要stat()编辑所有文件以获取详细信息，这会大大增加列出时间 - 无论 FS 使用散列结构还是线性结构，都会发生这种情况。
因此，即使 FS 有能力处理非常大的目录大小，也有充分的理由不使用大型扁平结构（它们也是要备份的猪）
我已经在一个目录中或以树结构排列的 32,000 个文件对 GFS2（集群）进行了基准测试 - 递归列表比在平面结构中获取列表快大约 300 倍（可能需要长达 10 分钟才能获得目录列表）
EXT4 显示了类似的比率，但由于终点只有几秒钟，大多数人不会注意到。