1

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).

1
  • My annoyance with this issue is increasingly growing. Anyone?
    – N-3
    Jun 2, 2015 at 11:22

2 Answers 2

2

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

  • Before I started the quick format. Format now took < 1min.

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).

0

I experienced a similar issue with thinly-provisioned logical volumes and XFS filesystem.

Basically, the problem was related to how XFS allocate its metadata: It writes some metadata, then seeks ahead, then allocate others metadata, and so on. As each metadata allocation triggers the underlying thin volume to allocate a different data block group, the process become quite slow.

I think your scenario is quite similar to that, even if using NTFS.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .