託管在精簡配置的 SAN 卷上的 Server 2012(R2) 中 LUN 的快速格式化需要很長時間
我現在遇到了 3 個不同的儲存供應商的這個問題，使用 3 個不同的 CNA 適配器（雖然都是 FCoE），所以我很確定這個問題不是孤立於特定的儲存供應商（在 HP 3PAR、EMC VNX 和 HDS 上看到的） G1000()。
當我們將精簡配置 LUN 添加到主機（通過 FCoE 連接，安裝了 MPIO）并快速格式化 LUN (NTFS) 時，最多需要 30 分鐘才能完成格式化。我找到了其他提到這個問題的執行緒 - 但到目前為止我還沒有找到解決方案/解釋。到目前為止，我們只能忍受它，但我必須說這很煩人。它似乎與 LUN 的大小無關 - 100GB 或 2TB，但仍需要 20-30 分鐘才能快速格式化驅動器！這更像是我書中的慢速格式。
其他人看到這個/有解釋嗎？到目前為止，我已經在 Windows Server 2012 (R2) 上看到過它——沒有在 2008 (R2) 上測試過。
我終於找到了一些時間來研究這個問題 - 我最初的懷疑被證明是正確的：它與 TRIM/UNMAP 有關，它在 Server 2012(R2) 中預設啟用。
我嘗試將新的 2TB SAN LUN 附加到主機並發出命令：
fsutil 行為設置 DisableDeleteNotify 1
- 在我開始快速格式化之前。格式化現在花費了 < 1 分鐘。
我不確定禁用 TRIM 是否是個好主意，所以現在我將在格式化所有 LUN 後再次啟用它。
fsutil 行為設置 DisableDeleteNotify 0
事後才想到：我記得有一個場景，我們也必須在物理機器上完全關閉 TRIM：日誌整合伺服器。未壓縮的日誌已移至此電腦（連接了精簡配置的 SAN LUN）。然後壓縮日誌。在壓縮過程中，驅動器的性能非常糟糕——直到我們關閉了 TRIM。
因此，Windows Server 和 SAN 之間的通信似乎出現了問題。很明顯，Windows 知道 SAN vol 支持 trim（因為我們在不支持 trim 的舊 SAN 上沒有看到這個問題）。