IBM and Windows Disk partition alignment

A question I get routinely asked relates to Windows disk partition alignment with XIV.   If you don’t know what I am talking about, take some time to read these very useful pages from our friends at Microsoft.  Once you have had a look, come on back and read my perspective.

Disk Partition Alignment (Sector Alignment): Make the Case: Save Hundreds of Thousands of Dollars

How to Align Exchange I/O with Storage Track Boundaries
Disk performance may be slower than expected when you use multiple disks in Windows Server 2003, in Windows XP, and in Windows 2000
Disk Partition Alignment Best Practices for SQL Server

Back already?   Hopefully you now know that  disk partition alignment is all about starting an IO at a logical block address that best matches how the underlying hardware stores your data.   So now your wondering, what does this have to do with XIV?  Well XIV has two concepts that relate to this:  cache and partitions.

XIV cache (the server memory used to speed up reads and writes) is organised into 4 KB blocks (which is nice and small).

So the XIV cache does not care about disk alignment.

But when it comes to writing and read from disk, the XIV writes data into chunks of consecutive logical block addresses (LBAs) that we call partitions.  These partitions are 1 MiB in size. What does that concept mean?  It means the magical number for XIV is 1024 KB or 1 MB.  (actually KiB and MiB, but for the sake of ease, I will stick to the naming used by Microsoft.   Given this number is fairly large (other hardware often aligns to 32KB, 64KB or 256KB), for XIV this reduces the potential impact of misaligned partitions.   Which is good.


Correct Windows Disk Alignment could give up to  a 7% performance improvement when using an offset of 1024 KiB. (1 MiB).  I need to be clear, that’s not a guaranteed improvement of 7%.  It’s a maximum possible improvement.  Your particular server will see an improvement somewhere between 0% and 7%.   It depends on your workload patterns.  The more small and random your workload, the more useful setting the 1024 KB offset will be.  The more sequential your workload, the less useful it will be,  as only the first and last parts of an I/O could potentially be misaligned.  This mis-alignment could equate to a tiny percentage of extra work for the XIV.   Sadly there is no metric you can display to detect how much impact misalignment is actually having.

So should you do it?   The good news is that new volumes created under Windows 2008 prefer the 1 MB boundary.  So a fresh install should already be using the correct values. The bad news is that volumes created under earlier Windows Operating Systems (Such as Windows 2000 and 2003) will almost certainly be misaligned, and correcting the alignment is destructive to the data in the partition.

How to check alignment at the host?  Here is an example:

I start diskpart:

Microsoft DiskPart version 6.1.7600
Copyright (C) 1999-2008 Microsoft Corporation.
On computer: ANTHONYV-PC

I list my disks.  In this example I have two disks installed in my laptop.  I select disk 0:

DISKPART> list disk
 Disk ###  Status         Size     Free     Dyn  Gpt  
 --------  -------------  -------  -------  ---  ---  
 Disk 0    Online          238 GB  5724 MB  
 Disk 1    Online          232 GB  1024 KB
DISKPART> select disk 0
Disk 0 is now the selected disk.

Now I list the partitions and see the offset for each one.

DISKPART> list partition
 Partition ###  Type              Size     Offset  
-------------  ----------------  -------  -------  
Partition 1    Primary            100 MB  1024 KB  
Partition 2    Primary            232 GB   101 MB

Partition  1 has an offset of 1024 KB, which is 1 MB, which is perfect for XIV.   Partition 2 has an offset of 101 MB, which is still on the 1MB boundary (it was pushed there by the combination of the size of the first partition (100 MB) and its offset (1 MB).   So this is perfect.

For an example of how to create a partition with the correct offset, check out this how-to document, that also provides some good follow on reading:

What about other IBM products?

The IBM SVC and Storwize V7000 prefers 64 KB (or larger) offsets as documented here:
Why?   Because the SVC and Storwize V7000 use a concept of grains, where each grain is usually 64KB or 256KB in size.

The DS8000 (regardless of model), also prefers 64 KB offsets.  The DS8000 use the concept of logical tracks where each logical track is 64KB.

The DS3000/DS4000/DS5000 range allow the user to set the segment size of a logical volume on creation.  The setting that you define should match the segment size defined for the logical drive being used.  In the example below, it is 64 KB.

What about VMWare?  

The answers are no different.   Misalignment can indeed make a difference to client performance.    Check this link from NetApp and this document from VMware: 

For an EMC perspective, check out this link from someone I respect a great deal, Chad Sakac:

I searched around looking for an image to highlight the theme of alignment.   I found this image in the IBM archives for the IBM Mass Storage Facility announced back in 1974. I am sure this product had some interesting alignment challenges.


About Anthony Vandewerdt

I am an IT Professional who lives and works in Melbourne Australia. This blog is totally my own work. It does not represent the views of any corporation. Constructive and useful comments are very very welcome.
This entry was posted in IBM XIV, Storwize V7000 and tagged , , , , , , . Bookmark the permalink.

7 Responses to IBM and Windows Disk partition alignment

  1. avandewerdt says:

    Thanks Alex!
    I added that link to the main body as it is very relevant, appreciate your support.

  2. Alex says:

    This one is also worth adding to the post:

    “Recommendations for Aligning VMFS Partitions – VMware”


  3. Michael Kostan says:

    Hi Anthony,
    I love your article. This topic has raised several good discussions among different infrastructure teams in our company.
    We are using XIVs and have virtualized the majority of our servers (mostly MS W2008) using VMware.

    Not sure if you can spend one more thought on this around VMware partition alignment and the 1024 KB LBA size?
    As VMware sits in-between the storage and server OS layer, the question comes up if VMware VMFS partitions should also be aligned with a 1024 KB offset?

    VMware best practice is to use the VI Client, because it automatically aligns VMware VMFS partitions when it creates them. In my opinion this statement is misleading because partitions always get created with a 64KB offset, no matter how the underlying storage infrastructure comes.

    Having a 1024 KB LBA size (offset) on the XIV, a 64KB VMFS partition start (1024 KB blocks afterwards) in VMware and a 1024 KB offset on the W2008 partitions screams “misaligned” to me.

    It would be great getting your opinion on this.
    Would you know if there are there any IBM articles/redbooks dealing with the VMware alignment question?

    Many Thanks.


  4. @dmVI says:

    Hi Anthony,

    Please correct me if I am mistaken, however the ramifications of your response to Michael’s query above is that customers utilizing VMware ESX with IBM XIV based datastores created using the vSphere Client (resulting in the default 64KB VMFS partition start) have misaligned VMFS datastores?
    If so, does that mean to rectify this issue the best practice would be the creation of VMFS volumes using the VMware CLI with the correct VMFS partition start point of 1024 KB for IBM XIV based storage?

    Lastly, I used the above google search to try and find a definitive response from the IBM site on the above outlined matter and kept getting links for your informative Blog post however no Redbooks/whitepapers for XIV and VMFS. Can I trouble you to provide a document I can use as a definitive source so that I can recommend accordingly to my customer?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s