For example, suppose that you write a 1 byte file to a hard disk that has an allocation unit size of 4 KB. Even though the file is only one byte, it will actually consume 4 KB of disk space because the disk is using a 4 KB allocation size. That means that the majority of the disk space in the allocation unit is wasted.
Larger files waste less disk space because they often consume multiple allocation units. For example, suppose you wrote a 10 KB file to a disk that used 4 KB allocation units. In this case, two and a half allocation units would be consumed, meaning that the overall amount of disk space wasted would be 2 KB.
Smaller allocation unit sizes waste less disk space. The problem with using smaller allocation units, though, is that it takes more of them to store a file than is needed with large allocation units. For example, it would take 262,144 4 KB allocation units to store a 1 MB file. The same 1 MB file would only consume 16,384 64 KB allocation units.
Allocation units are not always located sequentially. When disk fragmentation occurs, allocation units can become scattered across the volume. This means that on a fragmented volume, the number of required read head movements is proportional to the number of allocation units that make up the file being read. Larger allocation units allow more data to be read sequentially, even if the volume as a whole is fragmented.
Since databases in Exchange Server tend to be very large, it's beneficial to have larger-than-normal allocation unit sizes. According to Microsoft, you get the most benefit from using 64 KB allocation units when performing a streaming backup or database maintenance.
Many storage vendors provide their own recommendations for allocation unit sizes and use, and Microsoft recommends following them. If a vendor does not make any Exchange Server-specific recommendations, use 64 KB allocation unit sizes.
Aligning disk I/O
A lesser-known way to improve storage volume performance involves correctly aligning the disk partition. Exchange Server 2007 writes data to the information store in 8 KB increments -- ranging in size from 8 KB to 1 MB. When you prepare a volume using Windows's Disk Management console, the disk is almost always misaligned because of header information written at the beginning of a track. By creating an offset that is a multiple of 8 KB, you can prevent a single I/O operation from spanning multiple disk tracks, increasing the efficiency of database I/O operations.
NOTE:The following methods are destructive. Be sure to back up your data before attempting any of these techniques.
Some hardware vendors also offer proprietary tools for sector alignments. The procedure involves using the Diskpart tool, which works well. However, you should use a storage vendor-specific alignment tool if one exists and follow vendor recommendations. Additionally, this technique makes two major assumptions -- that the underlying storage is translated as 64 sectors per track and that you're using basic disks. If either of these conditions is not true, don't use this procedure.
You can find the partition alignment technique in a previous article. Although the explanation leading up to the method is geared toward older versions of Exchange, it's still valid.
About the author: Brien M. Posey, MCSE, is a five-time recipient of Microsoft's Most Valuable Professional (MVP) award for his work with Exchange Server, Windows Server, Internet Information Services (IIS), and File Systems and Storage. Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.
Do you have comments on this tip? Let us know.
Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.
This was first published in December 2009