我现在已经遇到了3个不同的存储供应商的问题，使用3个不同的CNA适配器（所有的FCoE），所以我相当确信这个问题不是孤立于特定的存储供应商（见HP 3PAR，EMC VNX和HDS G1000（）。
当我们向主机（通过安装的FCoE，MPIO连接）添加精简configurationLUN并快速格式化LUN（NTFS）时，格式化完成需要30分钟。 我发现其他线程提到这个问题 – 但到目前为止，我还没有find解决scheme/解释。 到目前为止，我们不得不忍受它，但我必须说，这非常恼人。 它看起来没有关系到LUN的大小 – 100GB或2TB，还需要20-30分钟来快速格式化驱动器！ 这更像是我书中的SLOW格式。
其他人看到/有一个解释？ 我目前在Windows Server 2012（R2）上已经看到了这一点 – 未在2008（R2）上进行testing。
我终于find了一些时间来看看这个问题 – 我最初的猜测certificate是正确的：它涉及到TRIM / UNMAP，它在Server 2012（R2）中默认启用。
我尝试将一个新的2TB SAN LUN连接到主机，并发出命令：
fsutil行为设置DisableDeleteNotify 1
我不确定将TRIM禁用是一个好主意，所以现在我将在我将所有LUN都格式化之后再次启用它。
fsutil行为设置DisableDeleteNotify 0
只是一个想法：我记得一个场景，我们不得不在物理机器上完全closuresTRIM：一个日志整合服务器。 未压缩的日志已移至此计算机（连接了精简configuration的SAN LUN）。 日志然后被压缩。 在压缩过程中，驱动器的性能非常糟糕，直到我们closures了TRIM。
所以在Windows Server和SAN之间的交stream中似乎有些事情要做。 很明显，Windows知道SAN卷支持修剪（因为我们在旧SAN上看不到这个问题，不支持修剪）。
我遇到了精简configuration的逻辑卷和XFS文件系统的类似问题。
基本上，这个问题与XFS如何分配元数据有关：它编写一些元数据，然后寻求前进，然后分配其他元数据，等等。 由于每个元数据分配都触发底层精简卷来分配不同的数据块组，因此该过程变得非常缓慢。
我认为你的情况是非常相似的，即使使用NTFS。