Why should you use Diskpar (Diskpart in W2003 SP1)?

Published 08-10-2005 03:32 PM 16.4K Views

Exchange Server can benefit from having basic disk partitions track-aligned.  Diskpar.exe is used for aligning a partition at the storage level, which, if used to create the partition, can have a significant positive performance impact on the storage and is highly recommended.   Before I go into the details of how to do this, I’ll give some basic definitions.  A partition is the container you create on an initialized disk to format and then use. Multiple partitions can be created on a single physical disk, and each partition will function as a separate disk (even though the partition will appear to be a separate disk, the total throughput of the physical disk is unchanged – so if you make two partitions on each disk and use them equally, they will each effectively only have half the available i/o rate.  This is important to keep in mind for capacity planning).   A sector is the smallest accessible unit on a physical disk, with multiple sectors comprising a track.  A partition that is track misaligned will occasionally cause 2 I/O operations instead of one depending on the actual drive geometry.


Even though some storage obfuscates sectors & tracks, using diskpar will still help by preventing misalignment in cache, or wasted cache.  If the disk is not aligned, every Nth (usually 8th) read or write crosses a boundary, and the physical disk must perform two operations.  At the beginning of all disks is a section reserved for the master boot record (MBR) consuming 63 sectors.  This means that your partition will start on the 64th sector, misaligning the entire partition.  Most vendors suggest a 64-sector starting offset, meaning that your partition starts on the 65th sector vs the standard 64th.  Check with your particular vendor before standardizing this setting on a particular storage array.  The key is to have it aligned on a 4 KB boundary from the start of the disk, of which choosing 64 sectors is 32 KB, and aligned.  (64 * 512 bytes per sector = 32,768 bytes)


It is important to differentiate the sector alignment, with file level fragmentation and allocation unit size.  Most Exchange Server I/O is random 4 KB read & write to the database .edb file.  We don’t notice a huge statistical difference in normal file fragmentation on a database LUN.  Since Exchange best practice is to place all database files in a storage group on the same LUN, as they grow, they will fragment each other pretty severely.  I have only heard of one case where serious file-level fragmentation impacted Exchange, and that was when a customer ran a 3rd party application on the same partition as the database files, and it created/deleted millions of very small files in a day.  If you dismount the databases, and perform an disk-level defrag, against each database LUN, you will eradicate the file level fragmentation.  It is not recommended to have any other files on the exchange database or log partitions (it is especially important not to share the log partitions with other programs, since log access to the drive is sequential, and random access to the drives hosting the drive will significantly reduce the performance.)


Exchange accesses the database file (edb) in random 4 KB read/write, which is, by default, the allocation unit size on the partition.  The default allocation unit size of 4 KB, which can be set at partition format, is the best practice.  If you use the default allocation unit size of 4096 bytes and have a starting offset that is a multiple of 4096 bytes, then your partition will always align on a 4 KB boundary. Setting the allocation size to be larger than 4 KB will disable NTFS compression [Exchange log and database files should always be uncompressed], and is useful in rare streaming backup solutions of extremely large databases where a larger allocation unit size will increase backup speed.




You have 2 switches, (i)nfo, and (s)et, and a parameter.  The parameter which you must add is the disk number.  This is discernable in disk manager (diskmgmt.msc)


1) First I query the disk and notice that the starting offset is 32256 bytes, which is not aligned.

C:\>diskpar -i 2


---- Drive 2 Geometry Infomation ----


Cylinders = 13056

TracksPerCylinder = 255

SectorsPerTrack = 63

BytesPerSector = 512

DiskSize = 107389255680 (Bytes) = 102414 (MB)


---- Drive Partition 0 Infomation ----


StatringOffset = 32256

PartitionLength = 107380998144

HiddenSectors = 63

PartitionNumber = 1

PartitionType = 7

2) Notice 32256 / 4096 = 7.875 , which is not an integer.   We want to change this to improve performance.

3) Now I set it to 64 sectors, and select the full available partition size.

C:\>diskpar –s 2            (yes, it’s really this easy)


---- New Partition information ----

StatringOffset = 32768

PartitionLength = 107388862464

HiddenSectors = 64

PartitionNumber = 1

PartitionType = 7

4) Now we get 32768 / 4096 = 8. Yeah!

5) Now open up disk manager and format the drive.




In Windows 2003 SP1, diskpart.exe has included diskpar.exe functionality.  The main difference is that diskpar creates a partition in sectors (512byte), and diskpart uses kilobytes.  In the example below we take a disk w/o any partitions and create it with the same starting offset of 32768 as the above diskpar.exe example.


Microsoft DiskPart version 5.2.3790.1830

Copyright (C) 1999-2001 Microsoft Corporation.

On computer: Exchange2003


DISKPART> select disk 1


Disk 1 is now the selected disk.


DISKPART> create partition primary align=32


DiskPart succeeded in creating the specified partition.









3rd Party:




- Robert Quimbey

Not applicable
I’ve been wondering why there wasn’t a (native) diskpar.exe tool for Windows Server 2003. Didn’t know that it was implemented in diskpart.exe (in Windows Server 2003 Service pack 1). Great!!!

... now I just need a SAN to test it on
Not applicable
Is there a command in Diskpart similar to -i in diskpar to check the geometry of an exisiting partition? I think I created it properly but I would like to check. Or is there some other way to do it?
Not applicable
You mentioned that Exchange Server I/O is random 4 KB read & write to the database .edb file. what is the KB read & write to .stm and .log? what should the allocation unit size be set for log drive and separate LUN for "backup to disk" purpose?

Not applicable
FYI: You can get the old diskpar from the Win 2000 Server Resource Kit (or Google it). Note that the the diskpart (with the "t") included with Win2k3 pre-SP1 did not support this track alignment capability, and you had to use the old diskpar from the resource kit... we've been waiting for the new version for a long time now!
Not applicable
Bryan Hoyt <is there a way to check w/o diskpar in diskpart after partition creation?>

When I use Diskpart to Show partition, it says the Offset is 32KB, when diskpar shows 32256. When I use diskpar or diskpart to make a proper 32768 offset, diskpar shows 32768, and diskpart still shows 32KB. Until I hear differently, I always doublecheck with diskpar on volumes I'm not sure of. On volumes I used DISKPART.EXE to create with a 32KB offset, I am confident they are correct.

Jackie - <KB read/write to stm/log. What should Allocation Unit Size be for those and the Backup Lun>

Jackie, it is Exchange best practice to keep the STM/EDB on the same LUN. The STM size varies but averages about 8kb in production. The log writes vary in size from 512b to the log buffer size. You will want to make sure that the starting offset is multiple of 4kb. Most vendors want 32kb, some 64kb. As for Allocation Unit Size, we have always recommended the default, 4kb.
Not applicable
You might want to check the spelling in in the compiled utility. "Information" is spelled wrong.
Not applicable

The Exchange team posted a good article just the other day about how disk alignment affects the performance...
Not applicable
With the use of virtualisation of disks in high-end SANs, eg IBM SVC, Veritas Volume Manager). Is there any advantage in sector alignment due to the disks being virtualised?
Not applicable
Rod - <...virtualisation of disks...Is there any advantage in sector alignment due to the disks being virtualised?>

The short answer is yes, but check with your storage vendor.

Even with virtualization there are issues with alignment in cache and on the physical disks. Some storage vendors require that all LUNs presented from the san be aligned. Some see perf wins on a per LUN basis, and some see cache utilization wins. I don't have any experience with Veritas, but can say you should align on Xiotech, EMC Symmetrix, HP-EVA/XP, and HDS storage. They each have slightly different recommendations but my default 4KB boundary rule of thumb is a good start.
Not applicable
Will you see a 1%, 5%, 10%, x% improvement with alignment? If you are able to isolate some of the spindles of the SAN, and perform a test when it won't impact mission critical services, it is always best to test and see.

Unfortunately, few administrators have the luxury of planning for, or hearing about alignment before the storage has partitions. To backup, wipe, recreate partitions with diskpar(t), and then restore is...painful.

So I personally recommend you test and see. If the performance win is x% more IOs, then you will be in a more informed position to decide whether it is then worth the effort to align all of your partitions. On new storage, without a doubt, ALIGN YOUR STORAGE.

A _great_ tool that Exchange has made, Jetstress, makes it very easy, and quick to see how many IO's your database LUNs can sustain. Run Jetstress on a database LUN, delete the partition, align it, then rerun the test with a backup of that database on the now

aligned partition. It should take less than 5hrs to run both tests.



Not applicable
Great explanation. Fortunaly i had an information from EMC about these details.

Here is onemore link http://www.emc.com/pdf/techlib/H959_clariion_bu_stor_ms_exch_snapview_ldv.pdf page 18

BTW:Can you ask the programmer to correct the typo "StatringOffset" :-)

Not applicable
In this technet article it says Create Partition Primary Align=X, where X is either 64 or 128. I noticed you used the value of 32 instead. Does it matter which value is the best to use?

Not applicable
Darth: align=32/64/128???

By default the gui will usually select a starting offset slightly smaller than 32kb. I choose 32kb as an example, because it fixes the core alignment issue. However, there are other factors, including cache usage, and the vendor will suggest the most optimal value. Many vendors suggest 64KB, and I've started hearing from folks in the field that some of the largest enterprise SANs are suggesting 128KB. Bottom line, Check with your vendor, and/or do a jetstress test and find out for yourself which is best.
Thanks, Robert
Not applicable

This is the final blog in my series about Exchange 2007 storage. In this blog I will...
Not applicable
If I have a Windows 2003 SP2 x64 server with a 2.8 disk for the Exchange databases using GPT instead MBR, must the disk be aligned too?
Version history
Last update:
‎Jul 01 2019 03:07 PM
Updated by: