Yesterday I posted about the mbrscan and mbralign tool that NetApp created. This triggered Nick Triantos of NetApp to write an excellent detailed technical article on why you need to set the alignment:
When setup routine queries the CHS (Cylinder / Head / Sector) information of the disk from the BIOS, the CHS data doesn’t actually corresponded to anything physical. At large LUN sizes, the S number (sectors per track) is always reported as 63, so partitioning is set at 63 sector starting offset.
The problem is that 63 sectors, corresponds to 32256 bytes or 31.5KB, which does not align with storage array’s logical block size. Physical disk blocks always correspond to 512 bytes in size, but for efficiency and performance reasons, disk arrays use a logical block size unit that is a multiple of the physical block size.
For the complete story visit Nick’s Blog on the NetApp website.
Would this optimization get wiped out if the vmdk were moved? (via storage vmotion for example)
I’m curious what the best practice for alignment is when you have a Windows VM that is attaching to a virtual RDM through ESX when placed on NetApp storage. I’m not sure if setting the LUN type in FilerView to “Windows” is enough in this case or not.
Precisely right — if using an RDM, you want to match the LUN type (when creating the LUN on the NetApp) to the guest OS that will be using the RDM.