Would it therefore be wise to reformat each drive that will be used for Exchange 2007 databases after they are created by SnapDrive? I'm just wondering why this isn't covered in any of the SME manuals or best practices guides. Or, maybe it is and I'm just missing it. If so please let me know.
Would it therefore be wise to reformat each drive that will be used for SQL after they are created by SnapDrive? I'm just wondering why this isn't covered in any of the SMSQL manuals or best practices guides. Or, maybe it is and I'm just missing it. If so please let me know.
NetApp virtualizes storage therefore for LUNs it's irrelevant if the OS drives are set for 64kb or anything else - we simply use 4K blocks. Formatting the OS partition to anything but default won't do anything for performance that I'm aware of based on this. SnapDrive uses the default size when formatting and that's 4kb (which is supported, not configurable). The biggest item that they need to validate is alignment - SD, CLI and FilerView set this correctly if a LUN is created for Windows/NTFS - I say validate because it's always good to ‘validate the vendor'.
NOTE: MS documentation is ‘vendor agnostic' therefore they won't address NetApp/WAFL and how/what we do.
I would not change the allocation size. SDW makes sure the file system is aliened correct according to the filer's 4kb block alignment requirements.
This makes sense. My storage experience started out with other solutions which allowed you to change the segment size on the storage controller itself.
However, I want to make sure there is no performance savings having the applicaiton and file system allocation size set the same. Some applications have a larger block size they use. Tivoli Storage Manager uses 256KB, Exchange uses 8 KB and I believe SQL may use a larger size. When I've implemented IBM storage for these applications we not only set the NTFS allocation size but we also alter the segment size on the storage.
All the microsoft documentation states raising the allocation size should be done and MS support simply refers customers to that doc. Again, it is clear raising the allocation size will have no performance gain on the storage system which still uses a 4KB block size. I'm just trying to understand if matching the Application and File system block sizes has any effect.
Please understand the main issue here is that I have customers who want to change this to MS recommendations and I need to be sure when is say "Yes, but with NetApp you don't need to do that" that I'm right. This is clouded a bit by the fact the customer believes their own performance testing has shown a gain in performance when they did so. I'm somewhat skeptical of the tests they ran though.
No, changing the application block size to match the file system block size has not effect with WAFL.
We see this all the time with SQL Server and Oracle. Typical database block sizes are 8K while the WAFL block size is 4K.
I was a non-believer when I came here 8 years ago, because I was used to adjusting things like extent sizes for performance reasons, etc. and there was no difference no matter what I set the extent size. WAFL simply takes care of the continuousness for you!
The initial size of the ESE database is small and the autogrowth pace seems to be an extent of 64mo… because of these limitations on initial size/ autogrowth parameters, the Exchange 2010 database is always in multiple NTFS fragments. So the more you grow the more you have fragments which can lead to to grow the File attribute list (FAL) which has a supported limit of 256ko. By going into 64ko NTFS allocation size you reduce the number of fragments and so the FAL size.
I'm still looking what the new switch /L for the Format command there talking here http://support.microsoft.com/kb/967351 and point to in the previous article and seems to be integrated in windows 2012
/L NTFS Only: Use large size file records.
By default, the volume will be formatted with small size