MFT 碎片會成為我繁忙的文件伺服器上的問題嗎？
從 SAN 掛載的 Windows Server 2003 SP2 LUN 數以百萬計的小文件，跨越數十萬個目錄（總共 100GB） 具有 4k 集群大小的 NTFS
在為備份進行初始文件抓取或歸檔正常使用者對該驅動器上文件的訪問時，速度會嚴重減慢。
SAN 和網路人員在初步調查中沒有表現出異常活動，但更深入的調查仍在繼續。懷疑 NTFS 或 Windows 存在某種伺服器級別的問題。
鑑於幾乎所有文件都小於 10k，因此適合 1-3 個集群，我不懷疑正常碎片是一個問題，但也許 MFT 碎片可能是一個問題。鑑於備份和清理即使在非工作時間也會導致使用者中斷，我猶豫是否使用 Windows 碎片整理來分析我的碎片，我真的只關心 MFT 碎片。有沒有比全盤分析更快地解決這個問題？
如果有人有建議，表現良好的第 3 方碎片整理程序也不是不可能的。我們的分析不會進一步打擾使用者是當務之急。
我們也在考慮為 NtfsDisableLastAccessUpdate 放入 reg 密鑰。有沒有人發現這確實是一個很大的改進，而不僅僅是一個小調整？
是否有任何好的工具來測量繁忙驅動器的文件鎖定/訪問爭用？來自 sysinternals 的 GUI 工具（如 procmon）不再在該級別進行擴展。
當您備份這樣的捲時，您將認真地使用底層儲存。當您開始讀取分散在文件系統中的數百萬個小文件時，限制因素將是 SAN 上的底層磁碟可以提供的隨機讀取 IOPS。SAN 本身可能根本不會受到壓力，但您正在讀取的捲將受到打擊，並且任何其他嘗試同時執行任何其他操作的程序都會受到影響，除非您限製備份活動。
要查看的是該卷上的隊列深度。如果它的峰值顯著高於備份卷的磁碟數量，那麼您將達到 IOPS 限制。Perfmon 會給你一個想法，但最好的數據將來自儲存陣列自己的分析，如果可能的話。我嚴重懷疑您的問題與文件鎖定有關。儲存人員需要查看 RAID 包中磁碟上的 IOPS，您的捲是從這些磁碟中分割出來的，我懷疑這些磁碟每個都超過 150 IOPS（如果它們是 15k，則更高，如果它們是 7.2k，則更低） . 如果您有一個託管該卷的 6 磁碟 RAID 10 組，那麼如果它真正備份數百萬個 10k 文件，那麼它的最大速度不會比 10Meg/sec 好多少，而且幾乎沒有大得多的文件。
NtfsDisableLastAccessUpdate 將對您的情況有所幫助 - 它從每個文件活動中刪除一組 IOPS，特別是它避免了與每個文件關聯的一些額外的讀取和寫入。鑑於您有數百萬並且您的文件非常小，應該會有一個重大的勝利，它可能高達 50% 的勝利。也就是說，您將看到的最有可能的效果是您的備份會加快速度，但仍會遇到 IOPS 限制。
如果尚未完成，您還應該考慮對齊磁碟分區。在這樣的情況下（大量的小讀取），它並不像其他 IO 模式那樣大，假設您的 RAID 條帶大小為 128k 並且您的平均讀取量約為 10k，可能約為 10%，但它可能值得努力。這將需要備份整個卷，重新分區和重新格式化，然後恢復數據，所以這不是一件容易的事。
在分析模式下執行磁碟碎片整理程序是我知道的查看您擁有多少 MFT 碎片的唯一方法。
如果音量是 24 x 7 使用的，那麼您可能會陷入“打擾”使用者的困境。如果沒有，請安排“defrag -a -v C:”命令在非工作時間執行，並將其輸出重定向到文件。這將為您提供命令輸出，無需您在周日凌晨 4 點醒著執行它。>微笑<
我不能給你統計數據：“NtfsDisableLastAccessUpdate”，但我肯定會設置它，除非你需要保存最後一次訪問時間。（我會使用“fsutil behavior set disablelastaccess 1”命令，而不是在系統資料庫中設置它。您也必須重新啟動才能使更改生效。）
如果您不需要，也可以考慮禁用 8dot3 文件名創建。執行此操作，尤其是當您在單個目錄中有大量文件時。（雖然關閉它不會擺脫已經存在的 8dot3 名稱……）
在這個緩慢的“初始爬行”之前/之後比較有問題的捲上的“fsutil fsinfo 統計資訊”的輸出可能會告訴你發生了什麼，儘管我認為它只會告訴你正在發生大量的元數據讀取.
您在 SAN 上是否有足夠的空間來將捲的全部內容還原到與生產 LUN 類似配置（考慮其 SAN 屬性——RAID 級別等）的新 LUN？看看一個從一開始就禁用了 8dot3 名稱創建的新鋪設的 NTFS 文件系統，也許還有一個不同大小的 MFT 區域，與生產 LUN 相比如何表現會很有趣。（如果暫存 LUN 被證明執行得更好，那麼通過將更改的文件從生產 LUN 複製到此暫存 LUN 來協調遷移也不會太困難。）