ou should format the drive using 64 KB allocation units. Yes, the SAN
element size, which is just the equivalent of the RAID stripe size, is 128
KB by default, but for a different purpose. The reason you want 64 KB AUs
at the Logical OS level is because it reduces the number of IOPS to get the
same amount of data plus SQL Server will execute asynchronous disk requests
by Extents, which are 8 x 8 KB data pages = 64 KB. It can also request up
to 2 Extents whenever it is attempting to execute Read-Ahead requests, which
is 128 KB, and would be 1 request but 2 IOPS if formatted as 64 KB AUs
versus 32 IOPS is formatted with the default 4 KB AUs. If the turnaround
time is about 10 to 20 milliseconds per IO request, a 16 fold increase in
transmission could be quite a windfall for performance.
However, and this has been debated, you may wish to format the separate
transaction log disks as 8 KB AUs as the transaction log is a serial process
that is not tied to Extents nor Read-Ahead operations. In this case,
aligning with the data page size would be preferable.
That being said, even though we have separated our Data files from TLog
file, and TempDB data from User DB data, we do dedicate and format SQL
Server database file drives all with 64 KB AUs and have increased our IO
If you need to support a high levels of Read IOPS, buy more, smaller disks
for the SAN, increasing the spindle count. If you need to support high
levels of Write IOPS, then by more HBAs and a Multipath solution for your
server. EMC makes PowerPath; Veritas has Volume Manager. And there are
many other products on the market which will do the same task.
Finally, along with properly formatting your disks, you also need to
consider properly aligning your NTFS volumes with the SAN track sectors.
This can be done either on the SAN or on the OS. On the SAN, it is called a
LUN Offset. On the Win2K OS, you can use the Resource Kit DISKPAR tool to
"sector" align the partition before you format it. For Win2K3, if you are
pre-SP1, use the DISKPAR utility; if post-SP1, use the OS DISKPART tool.
The difference is that DISKPAR will ask you for the number of sectors to
offset for alignment, DISKPART will ask you for the number of bytes. What
you want is 64 sectors = 32,768 bytes.
Here's the reason, for many modern disks, tracks contain more than 63
sectors/track, but NTFS was created when they were just 63 sectors/track,
and reserves the first track as the MBR header; so, it is unusable by the
OS. When you partition, you will end up starting at sector number 64,
assuming each track only contains 63 sectors. However, consider what
happens if you really have 64 or more sectors/track. If you request 4 KB
chunks, you will request the first seven just fine, but on the eighth, you
will ask for 4 KB, but there will only be 3,584 bytes left on the track; so,
to fulfill your request for 4,096 bytes, the first 3,584 bytes will be read
from the current track, but the final 512 bytes (one sector) will be read
from the adjoining track. That means you will have to incur the additional
latency of the seek time to move the disk actuator from one track to the
next, the slowest operation of any but the latest disks. If you use 64 KB
AUs, you will incur this additional latency with each and every IO
Now, the proper alignment depends on the number of sectors/track the
particular disks used in your SAN; so, get thi