我正在为我的项目实现缓存。在查看缓存目录结构之后，我看到了很多例子：
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实用程序，这些实用程序会占用有限数量的参数并一次删除大量文件，这往往是hacky（必须通过它find等）
真正的原因是什么？什么是“好的”缓存目录结构？为什么？
答案 0 :(得分：3)
每次我完成它，都是为了避免在文件系统中进行慢速线性搜索。幸运的是，至少在Linux上，这已经成为过去。
然而，即使在今天，使用基于b树的目录，一个非常大的目录将很难处理，因为只需要获取所有文件的列表需要一天又一天，不要介意找到正确的文件
答案 1 :(得分：2)
只需使用日期。由于您将按日期删除。 ：）
答案 2 :(得分：2)
如果你ls -l，所有文件都需要stat()来获取详细信息，这大大增加了列表时间 - 无论FS使用散列结构还是线性结构，都会发生这种情况。
所以即使FS有能力应对令人难以置信的大目录大小，也有充分的理由不使用大型扁平结构（它们也是备用的猪）
我已经在一个目录中以32,000个文件对GFS2（群集）进行了基准测试，或者以树形结构排列 - 递归列表比获得列表时的速度快300倍（当它们都处于扁平结构时）（可能需要长达10分钟）获取目录列表）
EXT4显示出类似的比率，但是终点只有几秒钟，大多数人都不会注意到。