ext4 中每個目錄的最大文件數
我管理一個包含文件儲存的應用程序，所有文件都儲存在其中，文件名等於它們的 md5 總和。所有文件都儲存在一個目錄中。目前有數千個，但很快它們應該是伺服器上的數百萬個文件。目前伺服器在 ext4 文件系統上執行 Ubuntu 11.10。
有人告訴我，將許多文件放在一個目錄中是不明智的，因為這會顯著增加查找時間和可靠性（他有一個關於單個目錄可以指向的最大文件的故事，從而導致一個大的連結列表）。相反，他建議使案例如文件名的子字元串創建子目錄。但是，這會使我的應用程序中的一些事情變得更加繁瑣。
這仍然是真的，還是現代文件系統（例如 ext4）有更有效的方法來處理這個問題並自然擴展？維基百科有一些關於文件系統的細節，但它並沒有真正說明每個目錄的最大文件數或查找時間。
ext3之後的文件系統支持散列 B 樹目錄索引。只要您執行的唯一操作是按名稱添加、刪除和訪問，這種擴展就非常好。但是，我仍然建議分解目錄。updatedb否則，您會為對目錄執行其他操作的工具（ 、ls、等）創建一個危險的陷阱，du如果目錄中的條目過多，這些操作可能會崩潰。
問題的核心是在目錄 inode 中探勘您想要的一個文件。一些文件系統比其他文件系統做得更好。有些規模接近數十億，但如果你只有…… 20K 文件獲取這些文件的速度明顯更快。此外，大文件數會為某些工具帶來問題，從而可能使備份/恢復成為一個更困難的問題。
碰巧我在我們自己的開發中遇到了完全相同的問題（md5sum 作為文件名，對其進行縮放）。我向我們的開發人員推薦的是將字元串切成碎片。他們以 4 人一組的方式進行，但在我們當時使用的文件系統上，從性能角度來看，即使有很多會被證明是有問題的，所以他們最終將前 6 個三元組分成 3 人組，其餘的留作終端目錄中的文件名。
4
4976/d70b/180c/6142/c617/d0c8/9d0b/bd2b.txt人組： 3 人組：
497/6d7/0b1/80c/614/2c6/17d0c89d0bbd2b.txt這具有保持目錄大小較小的優點，並且由於 MD5sum 非常隨機，它將創建平衡的目錄樹。最後一個目錄不可能得到超過幾個文件。並且在我們的程式碼中工作並不難。我們處理數百萬個文件項目，因此擴展對我們來說非常重要。