在精简配置的 SAN 卷上托管的 Server 2012(R2) 中的 LUN 快速格式化需要很长时间

Question

我现在已经在 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) 上测试过。

Answer 1

我终于找到时间来研究这个问题 - 而且我最初的怀疑被证明是正确的：它与 TRIM/UNMAP 有关，它在 Server 2012(R2) 中默认启用。

我尝试将新的 2TB SAN LUN 连接到主机并发出以下命令：

fsutil 行为设置 DisableDeleteNotify 1

• 在我启动快速格式化之前。现在格式化只需不到 1 分钟。

我不确定禁用 TRIM 是否是个好主意，因此现在我将在格式化所有 LUNS 后再次启用它。

fsutil 行为设置 DisableDeleteNotify 0

只是事后的想法：我记得一个场景，我们必须在物理机器上完全关闭 TRIM：日志整合服务器。未压缩的日志被移动到这台机器（连接了精简配置的 SAN LUN）。然后压缩日志。压缩期间驱动器上的性能非常糟糕 - 直到我们关闭 TRIM。

因此，Windows Server 和 SAN 之间的通信似乎出了问题。很明显，Windows 知道 SAN 卷支持修剪（因为我们在较旧的 SAN 上没有看到这个问题，它不支持修剪）。

Answer 2

我在精简配置的逻辑卷和 XFS 文件系统中遇到了类似的问题。

基本上，问题与 XFS 分配元数据的方式有关：它写入一些元数据，然后向前查找，然后分配其他元数据，依此类推。由于每次元数据分配都会触发底层精简卷分配不同的数据块组，因此该过程变得非常缓慢。

我认为您的情况与此非常相似，即使使用 NTFS。