一個 ext3 目錄中的最大文件數，同時仍然獲得可接受的性能？
我有一個應用程序寫入 ext3 目錄，隨著時間的推移，該目錄已增長到大約 300 萬個文件。不用說，讀取這個目錄的文件列表是非常慢的。
我不怪 ext3。正確的解決方案是讓應用程式碼寫入子目錄，
./a/b/c/abc.ext而不是僅使用./abc.ext.我正在更改為這樣的子目錄結構，我的問題很簡單：我應該在一個 ext3 目錄中儲存大約多少個文件，同時仍然可以獲得可接受的性能？你有什麼經驗？
或者換句話說；假設我需要在結構中儲存 300 萬個文件，那麼結構應該有多深
./a/b/c/abc.ext？顯然這是一個無法準確回答的問題，但我正在尋找一個球場估計。
如果您有一個支持該
dir_index功能的發行版，那麼您可以輕鬆地在一個目錄中擁有 200,000 個文件。不過，為了安全起見，我會將其保持在 25,000 左右。如果沒有dir_index，請嘗試將其保持在 5,000。
非常小心如何選擇目錄拆分。“a/b/c”對我來說聽起來像是災難的秘訣……
不要盲目地做幾個目錄深度結構，比如第一級有 100 個條目，第二級有 100 個條目，第三級有 100 個條目。我去過那裡，做到了，得到了夾克，當性能因數百萬個文件而陷入困境時，我不得不對其進行重組。:-)
我們有一個客戶端進行“多個目錄”佈局，最終每個目錄只放置一到五個文件，這正在殺死它們。在這個目錄結構中做一個“du”需要 3 到 6 個小時。這裡的救星是 SSD，他們不願意重寫這部分應用程序，而 SSD 將這個 du 時間從幾小時縮短到幾分鐘。
問題是目錄查找的每一級都需要查找，而且查找非常昂貴。目錄的大小也是一個因素，所以讓它更小而不是更大是一個很大的勝利。
要回答您關於每個目錄有多少文件的問題，我聽說 1,000 被稱為“最佳”，但 10,000 的性能似乎還不錯。
所以，我推薦的是一級目錄，每一級是一個 2 個字元長的目錄，由大小寫字母和數字組成，頂層大約有 3800 個目錄。然後，您可以使用包含 3800 個文件的子目錄保存 14M 文件，或者對於 3M 文件，每個子目錄大約 1,000 個文件。
我為另一個客戶做了這樣的改變，它產生了巨大的變化。