Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I saw article about Disk alignment here and also here.Also there where some references that windows server 2003 has some problem with disk alignment. After reading article I am confused whether we need to align the Disk alignment manually or it will be done automatically when we do partition the disk. What we do generally is when installing OS we perform disk partition and then for extra disk which added we do partition by using diskmgmt.msc(Disk management) So whether we require to do any alignment for windows server 2012 server also?

share|improve this question

Windows Server 2008 and newer versions will automatically align partitions optimally. There's nothing you need to do. This was a problem in older versions of Windows. The first paragraph in the summary section of this Disk Partition Alignment Best Practices for SQL Server whitepaper makes mention of this functionality (the paper is SQL Server-related, however the statement about partition alignment is generic to Windows Server).

share|improve this answer
ok. So for windows server 2003 R2 we need to disk alignment. – IT researcher Jan 18 '14 at 9:12
As a matter of fact, the problem is the old windows did IIRC a 16kb start segment - so everything was off (for example for 64kb segments ). Windows 2008+ does a 512kb block that it leaves empty, so everything is aligned to 512kb, which fits perfectly to pretty much every raid setup. – TomTom Jan 18 '14 at 9:15
+1 for this. I'm ready to put this question to bed. It's almost as tired as 'how big do I make my pagefile'. – Ryan Ries Jan 18 '14 at 13:51

Because the physical seek time on a spinning hard disk is so slow relative to the processor's ability to process data, it turns out it makes sense to tune the read/write block size and the software timing to consider these disk delays which are usually by far the slowest part of the data base.

I recall the early computer systems which were used by the airlines to book flights. They worked as well as they did with a very heavy load and very slow hardware by today's standards partly because engineers very carefully figured out how to match the software timing to the hardware timing. Records were kept of a size that made sense for the disk, something we almost never think about today, but something that can actually significantly improve thru-put on a very busy system. So software was designed to the hardware with no abstraction layer in the middle.

For very busy hardware this is still an idea which makes sense today, although it seems at the moment hardware is relatively cheap and it's easier to throw hardware at most problems to get the needed speed.

share|improve this answer
-1. Interesting story but does nothing to answer the question. – Grant Jan 18 '14 at 13:51

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.