I've now experienced this issue with 3 different storage vendors, using 3 different CNA adapters (all FCoE though), so I'm fairly sure this issue is not isolated to a specific storage vendor (seen on HP 3PAR, EMC VNX and HDS G1000().
When we add a thin provisoned LUN to a host (connected via FCoE, MPIO installed) and quick format the LUN (NTFS) it takes up to 30 minutes for the format to complete. I have found other threads around that mentions this issue – but so far I've yet to find a solution/explanation. So far we've just had to live with it, but it's pretty annoying I must say. It does not appear to be related to the size of the LUN – 100GB or 2TB, it still takes 20-30mins to QUICK format the drive! That's more like SLOW format in my book.
Anyone else seeing this/have an explanation? I've seen it on Windows Server 2012 (R2) so far – not tested on 2008 (R2).
Best Answer
I finally found some time to look into this issue - and my initial suspiecisions proved to be right: It's related to TRIM/UNMAP, which is enabled per default in Server 2012(R2).
I tried attaching a new 2TB SAN LUN to a host and issued the command:
fsutil behavior set DisableDeleteNotify 1
I'm not sure that it's a good idea to leave TRIM disabled, so for now I will enable it again, after I've formated all my LUNS.
fsutil behavior set DisableDeleteNotify 0
Just an after thought: I remember one scenario, where we had to turn off TRIM altogether on a physical machine as well: A log consolidation server. Uncompressed logs were moved to this machine (with a thin provisioned SAN LUN attached). The logs were then compressed. Performance on the drive was horrible during the compressions - until we turned off TRIM.
So something seems to be off in the communcations between the Windows Server and the SAN. It's clear that Windows knows that the SAN vol supports trim (because we do not see this issue on our older SAN, which does NOT support trim).