托管在瘦配置的SAN卷上的LUN in Server 2012(R2)的快速格式占用时间

Question

现在，我已经在3个不同的存储供应商身上经历了这个问题，使用了3个不同的CNA适配器(虽然都是FCoE )，所以我非常肯定这个问题并不孤立于特定的存储供应商(见HP3PAR、EMC VNX和HDS G1000() )。

当我们向主机(通过FCoE连接，安装了MPIO )并快速格式化LUN (NTFS)时，需要30分钟才能完成格式。我已经找到了其他提到这个问题的线索--但到目前为止，我还没有找到一个解决方案/解释。到目前为止，我们不得不接受它，但我必须说，这是相当烦人的。它似乎不相关的大小，伦-100 20或2TB，它仍然需要20-30分钟来快速格式化的驱动器！这更像是我书中的慢格式。

还有人看到这个/有什么解释吗？到目前为止，我已经在Windows 2012 (R2)上看到了它--没有在2008年(R2)进行测试。

Answer 1

我终于找到了一些时间来研究这个问题--而我最初的悬念被证明是正确的:它与TRIM/UNMAP相关，它在Server 2012(R2)中每默认启用一次。

我尝试将一个新的2TbSanLUN附加到一个主机上，并发出了以下命令：

DisableDeleteNotify 1行为集

• 在我开始快速格式之前。格式现在用了<1分钟。

我不确定这是一个好主意，让修剪禁用，所以现在我将再次启用它，在我已经形成了我所有的隆斯。

行为集DisableDeleteNotify 0

只是想了想:我记得一个场景，在物理机器上，我们不得不完全关闭TRIM :日志整合服务器。未压缩的日志被移动到这台机器上(附带了一个瘦配置的SAN )。然后对原木进行压缩。在压缩过程中，驱动器上的表现很糟糕--直到我们关闭了修剪。

所以在Windows和SAN之间的通信中似乎出现了一些问题。很明显，Windows知道SAN卷支持trim (因为我们在旧的SAN上没有看到这个问题，它不支持trim)。

Answer 2

我也经历过一个类似的问题:配置稀疏的逻辑卷和XFS文件系统。

基本上，这个问题与XFS如何分配其元数据有关:它编写一些元数据，然后进行搜索，然后分配其他元数据，等等。当每个元数据分配触发底层瘦卷来分配不同的数据块组时，进程变得非常慢。

我认为您的场景非常类似，即使使用NTFS。