RAID / Non-RAID Partition Alignment for max performance

[techspec6]

I created an excel spreadsheet that auto-calculates whether your raid array is properly aligned. It also auto-calculates non-raid partitions. You must meet the requirements of all Rules to be considered Aligned.

Using this spreadsheet's calculations, TechPowerUp!'s W1zzard wrote a great Javascript applet that calculates SSD alignment without the need to download the spreadsheet! The Javascript applet is linked below.

You must input your own data. It will not fetch your system information automatically. That's why the example column is there.

Let me know of any corrections or additions I can make to the sheet.

Partition alignment is the single most important performance tweak you can do for any SSD.

Lets break it down to it's simplist form. The SSD is divided into Blocks of 512k which are divided into pages of 4k in most cases. 128 pages = 1 block.

There is a certain amount of space before the start of the first partition, which is what is referred to as the offset. Vista and W7 use a default offset of 1024k, meaning there's 1024k of empty space before the partition. Starting at 1024k means that the partition starts at the beginning of the third block, since blocks are 512k (512k x 2 = 1024k).

The goal is to not start a partition in the middle of a block or a page. That way, you don't split any boundaries. If you split a page (4k) section, then 2 writes are necessary to write the page instead of 1, doubling the work. It will happen repeatively every 8th page, reducing overall performance and I/O commands. Blocks have a similar performance hit but not to the same degree as pages. It's easy to align to both.

Alignment has to be done when the partition is created. There are tools such as a gparted boot CD that can change alignment after it's created, but it's not 100%. Sometimes, you can lose your data with that method. It's best to fresh install and correctly create the partition at the beginning.

If you're running Vista or W7, the alignment is done automatically by the OS as long as you use the installation DVD to create the partition. WinXP is another story because it will not align a partition correctly by default. Extra steps are involved. The easiest way to align a WinXP OS volume is to get the downloadable Vista Recovery DVD and create the OS partition before the installation of WinXP. The partition created by the Vista Recovery DVD will be the same as the Vista Installation DVD and will be aligned at 1024kb by default which is a valid alignment for todays hardware.

It takes a moment to wrap your head around the new technology, but the sooner you forget HDDs, sectors, tracks, and cylinders, the better off you'll be. It's all about the blocks and pages now.

Online SSD Alignment Calculator written by TechPowerUp!'s W1zzard.

VBScript Alignment Checking Tool originally written by TcpDump's Tom Hirt. Discovered by Halk and edited by me to work with all SSDs with 512kb block sizes. Special thanks to darkwish for fixing the overflow error and bjd223 for correcting the drive volume output size.

SSD Alignment Spreadsheet created by me.

Jason

[techspec6]

Spreadsheet download available in Post #1


UPDATES:
*1.1 - updated to add a NAND field incase future pages aren't 4096.
*1.2 - Added non-raid single disk alignment checking.
*1.3 - Added Rule#3 to non-raid section. It's debatable, but only requires you use an offset greater than 512kb or 1024sectors, so it doesn't hurt. Vista and W7 both use 1024kb or 2048sectors by default, both of which meet this criteria.
*1.4 - Added more support for future and non-Vertex drives.
*1.5 - Simplified the layout and color scheme.
------------------------------------------------------------------

OCZ Drive Specifications:

To date, all OCZ drives have the same NAND Page and Erase block size.
NAND Page = 4096 bytes (4k)
NAND Erase Block Size = 524288 bytes (512k)

------------------------------------------------------------------

Consolidated list of threads containing info on parititon alignment:

http://www.ocztechnologyforum.com/fo...ad.php?t=48309 by therookie
http://www.ocztechnologyforum.com/fo...ad.php?t=55238 by Chrisped
http://blogs.msdn.com/jimmymay/archi...-template.aspx
http://www.ocztechnologyforum.com/fo...ad.php?t=50376 by Tony

**Notice- These guides will recommend all sorts of partition offsets. SSDs are divided into pages and blocks. Early guides did not take in the importance of aligning to blocks, but instead only pages. Please use the recommended partition alignment of 1024kb (Vista and W7 default) or you may not be aligned to the blocks which can result in less IO performance.

------------------------------------------------------------------

Commands to check alignment:

start > run > type "cmd" to enter command prompt, then type "wmic partition get Name,StartingOffset,Size". This method works in XP, Vista and W7.

or

within windows, type msinfo32. When the info program runs, navigate to Components > Storage > DISKS and look for "partition starting offset" with a value in bytes. This method works in XP, Vista and W7.

------------------------------------------------------------------

Some alignment misconception:

I've seen some on the forum state that "sectors/track" is what to check when looking at alignment. That is incorrect.

In Tony's post HERE, he states that the start of the first partition begins on sector 63 in Windows XP which we all know as the default misaligned partition. Sector 63 is the same as 32256 byte offset. Sectors/Track is a totally different disk parameter and has NOTHING to do with disk alignment. Tony was not referring to Sectors/Track.

The math behind it is: starting offset / bytes per sector = starting sector boundary
In the case of windows xp: 32256 / 512 = 63rd sector (not sectors/track)
In Vista/W7: 1048576 / 512 = 2048

HERE is a good read on how disk technology has evolved and why "63 sectors/track" means nothing.

Jason

[Digikid]

LOL! Fastest update ever!

Thanks!

[2Luke2]

It should be wmic partition get Name, StartingOffset with no space in Starting Offset.

[techspec6]

ahh, good catch. Thanks! Must have gotten spacebar happy there. I changed the excel file to remove the spaces but I won't bother updating the pic, atm.

To help distinguish which disk is which, you can toss "Size" onto the string too, assuming your disk are all different sizes anyways.

ex: wmic partition get Name,StartingOffset,Size

Jason

[techspec6]

consolidated to earlier thread.

Jason

[Ian]

This is great thanks :thumbs:

a simple script to get info and output the result into the spreadsheet and then display the result in one easy step would also be handy if you'd like to take this to the next level!!

[techspec6]

consolidated to earlier thread.

Jason

[techspec6]

consolidated to earlier thread.

Jason

[PC-Lover]

Looks very professional. Thanks guy.

[Ian]

Some alignment misconception...

I've seen some on the forum state that "sectors/track" is what to check when looking at alignment. That is incorrect. It's because of the number 63 where some have gotten confused. In Tony's post HERE, he states that the start of the first partition begins on sector 63. He's correct and this is an example of a misaligned partition. Sectors/Track is totally different, though. Therefore it's all Tony's fault and we'll blame him for now...

The math behind it is: starting offset / 1024 * 2 = starting sector
In the case of windows xp: 32256 / 1024 * 2 = 63! misaligned, same number, but not sectors/track
In Vista/W7: 1048576 / 1024 * 2 = 2048

Jason

edit - HERE is a good read on how disk technology has evolved and why "63 sectors/track" means nothing.

Now you've done it! lol If anyone had any doubt as to what is going on here, now they are going to be completely confused

No disrespect you are correct, but I think this is a subject which should be kept simple to avoid the mass confusion that exists..

[techspec6]

lol, i'll try to word it better. Stay tuned ;-)

Jason

edit - That's about as simple as it gets. It's not a simple process unless the partition is created with Vista and beyond. Then it's basically automatic.

[coodiggy]

Thanks for the info Jason. I tried creating and formating a volume/partition using the vista repair/recovery disc and diskpart method for alignment on a small hdd for practice. The disk is setup on my onboard raid controller as a single disk stripe. I don't remember what my stripe size was or what I chose for the alignment offset, or the alocation unit: doh... I went into msinfo32 and looked at the disk info and found the partition starting offset to be 131072 bytes, so I think it worked for this disk. 131072 / 1024 * 2 = 256

[techspec6]

It's very important to match the stripe boundary as well. I suggest going into your raid BIOS and checking it out.

You are currently aligned with a 128k (256 sector) offset. That is only 1 of the 5 rules listed in the first post.

Your situation currently is:
Rule 1 - unknown
Rule 2 - aligned
Rule 3 - unknown but probably aligned
Rule 4 - unknown
Rule 5 - aligned

Jason

[coodiggy]

Went back into the BIOS and checked the single disk config; HDD0 on nvraid p-ata, configured as a one disk stripe with striping block set to 16K ~what is this? do I need to multiply by 1024 to get stripe block size in total bytes?

alignment probly was set to an offset of 128 in diskpart, I just can't remember.. I do remember that I formatted the partition with FS=fat32 with default allocation unit of 16 kilobytes ~assuming * 1024 = 16384 Bytes
If I'm getting this right; stripe block size =16kilobytes or 16384 Bytes
partition offset= 128k or 131072 Bytes

Partition offset / stripe block = integer value of 8
simplified; 128/16=8

Stripe unit size 16/alocation unit 16 =1
I guess if my partition offset is 131072, and I was using the vertex drive, the nand erase block at 524288, I would get a rule number 5 value of .25 = not aligned; is this multiplied by the number of drives in the array?



Since I am doing this on the one physical disk for practice, and my goal is to decide what I want to set my vertex array up as, in regards to stripe size and file alocation unit; using 4 physical disks, I am interested in finding out how the file alocation unit is related to the number of disks; while keeping in mind that I need to keep the stripe size/boundry and partition starting offset aligned.

In reference to starting sector boundry;vs stripe block; to allign my stripe size to the starting sector boundry; I would have to use a stripe size of 128k "max that my board supports is 128k" so If stripe unit size is in kilobytes; a file less than 128K, like a 30-40K system file is going take up 128k on the disk... That's alot of slack..

I might be better off using 64k stripe size and 64k offset to keep the stripe lined up with the offset boundry and reduce slack from all the files smaller than 64k...