應該將多少個子目錄放入一個目錄

Question

在SO上，有很多關於目錄中有多少個文件是合適的討論：對於較新的文件系統，在較新的文件系統保持低於幾十萬的情況下保持低於千分之一。 通常建議爲每幾千個文件創建一個子目錄。

所以接下來的問題是：我應該放入一個目錄的子目錄的最大數量是多少？嵌套它們太深會殺死目錄樹遍歷性能。有一個嵌套他們淺？

Answer 1

從實用性的角度來看，應用程序可能無法很好地處理大型目錄條目。 例如，Windows資源管理器陷入數千個目錄條目（我有Vista崩潰，但XP似乎更好地處理它）。

由於您提到了嵌套目錄，因此請記住全限定（驅動器標識符和路徑）文件名的長度有限制(See wikipedia 'filename' entry)。這將隨操作系統文件系統(See Wikipedia 'comparison on file systems' entry)而變化。

對於Windows NTFS，它應該是255，但是，我遇到了具有完全限定文件名的命令和API函數的問題，大約有120個字符。我在映射網絡驅動器上使用長路徑名時也遇到了問題（至少在Vista和I.E. Explorer 7中）。

此外，子目錄的嵌套級別也有限制。例如，CD-ROM（ISO 9660）限於8個目錄級別（如果要將目錄結構複製到CD-ROM或其他文件系統，請記住這一點）。

因此，當您將文件系統推到極端 （而文件系統可能能夠理論上處理它，應用程序和庫不可能）時，會有很多不一致。

Answer 2

真的取決於您使用的操作系統，因爲目錄操作是使用系統調用完成的。對於基於unix的操作系統，i-node查找算法效率很高，目錄中文件和文件夾的數量無關緊要。也許這就是爲什麼在基於Unix的系統中沒有限制。但是，在Windows中，it varies from file-system to file-systems。

Answer 3

哇，你真的在​​創造這麼多文件嗎？也許你應該重新審視你的文件創建策略:-)。

說真的，我不能想到很多情況下，即使我的子目錄中有一千個文件。當然不是可執行文件或配置類型。

也許日誌型文件能拿這些類型的數字，但是，即使你創造了每分鐘一個日誌文件（爲什麼你會嗎？），這仍然只有1400多元的一天。

然後每天只有一個子目錄，需要幾年的時間才能達到一千個子目錄。

Answer 4

通常現代文件系統（如NTFS或ext3）沒有直接訪問文件的問題（例如，如果您嘗試打開/foo/bar/baz.dat）。你可以遇到問題的地方是枚舉給定目錄中的子目錄/文件（即給我所有來自/ foo的文件/目錄）。這可能發生在多種情況下（例如，在調試時或備份期間等）。我發現最多保留幾百人的子女數量給了我可接受的迴應時間。

當然，這從不同的情況來的情況，所以做測試:-)

Answer 5

我的猜測是儘可能少。

在我工作的ISP（早在2003年），我們有很多用戶電子郵件和網頁文件。我們用md5散列用戶名（深度3級）（即/ home/a/b/c/abcuser）來構建它們。這導致第三級目錄中可能有多達100個用戶。

您也可以在淺層結構中製作更深的用戶目錄結構。最好的選擇是嘗試查看，但查找的速度越快，目錄數越小。

Answer 6

我最近遇到過類似的情況。我們使用文件系統來存儲序列化的交易細節。這些只會很少看到，將它們存儲在數據庫中是不值得的。

我們發現，Windows和Linux應付了一千元左右的文件，但它沒有得到更慢訪問他們 - 我們在子顯示目錄中的邏輯分組組織他們，這解決了這個問題。

grep他們也更容易。通過數千個文件進行擦除比轉換到正確的子目錄和擦除幾百個文件要慢。

Answer 7

我發現硬盤的方式，對UFS2限制是大約2^15子目錄。因此，雖然UFS2和現代文件系統在目錄中幾十萬個文件正常工作，但它只能處理相對較少的子目錄。非明顯的錯誤消息是「無法創建鏈接」。

雖然我還沒有測試ext2，但我發現了各種郵件列表發帖，其中海報在ext2文件系統上也有超過2^15個文件的問題。

Answer 8

在windows API中，maximum length設置爲260個字符。 unicode函數確實將此限制擴展到主要文件系統使用的32767個字符。