緩存目錄結構

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顯示類似的比率，但因爲終點只有幾秒鐘，大多數人都不會注意到。