NTFS 資料夾之 130 萬魔咒

分享最近遇到的一起案例，讓我對「單一 NTFS 資料夾包含過多檔案」的問題有了新的認知。

Windows 資料夾的同一層放太多檔案會出事已屬常識，過去處理過多次：

• 超過一百萬個檔案的 NTFS 資料夾…
• 清理內含 750 萬個檔案的資料夾

常見的副作用通常是：檔案總管開資料夾會卡死甚至搞到桌面凍結、DIR 指令無法完成、程式取檔案清單跑不完... 等。依我的理解，問題主要發生在列舉或搜尋檔案行為，若檔案名已知，對個別檔案讀寫並不致出現嚴重效能問題(參考，網上有 1400 萬個檔案的案例)。最近遇到一起案例，刷新了我的認知。

狀況是某主機近期效能忽然急劇惡化，經過一番調查，查可能與 Log 寫檔有關。在特定情境程式會將資訊存成獨立新檔備查，但由於未定期清理，多年下來檔案數量逐漸成長，就在幾天前突破了 130 萬。寫檔採同步執行，寫完才會回傳結果，故當檔案寫入耗時過久，確實會導致效能問題。

莫非，效能惡化跟檔案數破 130 萬有關聯？

查到 Dell 有篇超讚的研究 - Avamar: Slow performance restoring folder with >1 million files due to 8.3 file names enabled，單刀直入給了答案 - 是的! 130 萬還真的是個他 X 的地雷數字。

Dell 的實驗方式是在同一目錄持續建立新檔案，記錄建立多少個檔案需多少時間，分別測試啟用 8.3 檔名(紅線)及停用 8.3 檔案(綠線)。綠色是一條等比例的健康直線，5 百萬個檔案約一個小時可建完。紅線則在 120 萬左右出現戲劇化轉折，新增檔案所需時間呈指數型上升。研究報告有個讓人驚心的結論：

Performance stalls at ~1.3 million files when 8.3 names setting is enabled.
當啟用 8.3 檔名支援且檔案數達到約 130 萬，效能會開始烙賽。

知道問題所在，解決便在彈指之間：儘量別在單一資料夾塞超過 30 萬個檔案，若非要不可，請停用 8.3 檔名。

Windows 用了超過三十年，繼續學到新知識。