Last revision: 6/26/2011, GPT fdisk version 0.7.2
I'm a technical writer and consultant specializing in Linux technologies. This Web page, and the associated software, is provided free of charge and with no annoying outside ads; however, I did take time to prepare it, and Web hosting does cost money. If you find GPT fdisk or this Web page useful, please consider making a small donation to help keep this site up and running. Thanks!
|Donate $1.00||Donate $2.50||Donate $5.00||Donate $10.00||Donate $20.00||Donate another value|
Note: This page is part of the documentation for my GPT fdisk program.
Ideally, partitioning using GPT should be easier than it is for MBR. There are no distinctions between primary and logical partitions, and the lack of CHS geometry issues enables simpler partition placement rules. All of this is true in many cases, but there are situations in which other factors come into play that can muddy the waters again.
In many cases, you can create partitions using GPT in much the same way you'd do with MBR: Place one after the other with no gaps between them and ordering them in whatever way is convenient. Various documents on the Web, however, advise certain procedures when creating GPT partitions. For instance, Apple advises, in its Technical Note TN2166, the following:
Windows seems to follow similar rules when creating GPT partitions. GNU Parted can create cylinder-aligned partitions, but doesn't seem to follow Apple's suggestions. Depending on how you want to use the disk, you may want to follow some or all of these rules yourself. In particular, creation of an ESP, which is normally formatted with a FAT32 filesystem, makes sense on any boot disk. Even if your system uses BIOS, you might find an ESP to be a useful place to put boot loader files. (In this respect, the ESP is similar to a separate Linux /boot partition.)
On BIOS-based systems, a BIOS Boot Partition (GPT fdisk code EF02) plays a role that's similar in some ways to the ESP. The BIOS Boot Partition can hold a second-stage boot loader for GRUB 2. This is helpful because on an MBR disk, GRUB 2 hides data in the otherwise unused and unallocated space between the MBR and the start of the first primary partition. This unallocated and unused space may not exist on a GPT disk, so another place is needed to store the data. If you're in doubt, go ahead and create a small BIOS Boot Partition of about 100 KiB to 1 MiB. At worst, it'll consume a small amount of disk space.
MBR disks often use partitions that begin only on sectors that are multiples of 63. This is because modern hard disks almost always appear to have 63 sectors per cylinder in the CHS geometry scheme, and partitioning tools have traditionally begun partitions on cylinder boundaries. (Disks with other than 63 sectors per cylinder will have other sector alignments on MBR disks, of course.) Today, though, CHS geometries are largely fictions, so these partition placement rules serve no real purpose, aside from keeping old OSes and utilities happy. Some recent MBR partitioning tools, including those that ship with Windows Vista and later, therefore abandon these old rules in favor of rules that are designed to satisfy newer issues:
In both of these cases, performance can be degraded if partitions are not properly aligned. You should first understand that modern filesystems employ data structures that are 4 KiB, or larger multiples of that amount, in size. Thus, when an OS modifies one of these filesystem data structures on a disk with a smaller logical than physical sector size or on a RAID array, performance will be optimized if the partition is aligned to match the underlying disk sector or stripe size. If the partition is not so aligned, the write operation will entail an extra read operation (for disks with 4096-byte physical sectors) or writing to two stripes even for small writes. Such operations take extra time, and so disk write performance can be impacted. Depending on the filesystem in use, performance when writing many small files to disks with 4096-byte physical sectors can be degraded by as much as a factor of 25 in benchmarks I've run—that is, an operation that takes one second on a properly-aligned partition can take up to 25 seconds on a misaligned partition! (My full writeup on the issue appears on the IBM developerWorks site.) Issues surrounding RAID requirements are similar, but not as dramatic. Web sites I've consulted, such as this page on Linux hardware RAID optimization, or a Microsoft page on SQL administration, claim a 10–40% performance difference between properly aligned and misaligned partitions.
One difference between RAID alignment issues and those of drives with 4 KiB physical sectors is that the RAID stripe size is typically in the range of 16–128 KiB, or sometimes as high as 256 KiB. Microsoft has opted, in Windows Vista and later, to employ a policy of creating partitions at 1 MiB boundaries. This figure may seem like overkill compared to the needs of RAID arrays and especially disks with 4 KiB sectors; however, there's very little downside to it. It's rare that a partition size must be measured in units of less than 1 MiB, so you're unlikely to waste space between partitions by placing partitions at 1 MiB boundaries. Using such a policy will waste close to 1 MiB of space at the beginning of the disk, but on a modern disk with a capacity measured in the hundreds of gigabytes or even over a terabyte, 1 MiB is a tiny amount of space.
GPT fdisk has been moving toward a similar policy since version 0.5.2, which rounded partition start points to 8-sector (4 KiB) boundaries by default. A bug in version 0.5.3 prevented proper automatic alignment, but versions 0.5.4 through 0.6.5 attempted to implement proper alignment for drives with 4 KiB sectors. Version 0.7.1 implements a more complex set of alignment rules:
The intended net effect of these rules is to provide a default alignment on new disks that will be suitable for all current hard disks and common RAID array configurations, without causing concern, confusion, or annoyance to users of smaller-than-298 GiB disks with conventional 512-byte physical sectors whose disks were previously partitioned using other than a 2048-sector alignment. Some specific cases will fall through the cracks, though. If you've got a single over-298 GiB disk that doesn't need or use 8-sector alignment, GPT fdisk will nag you about this when you verify your disk. I apologize for this, but given the massive performance problems on the new breed of disks with 4096-byte sectors, I felt it was more important to err in this way than to let a problem go unremarked. On the other hand, if you've got a small (sub-298 GiB) RAID array that was improperly aligned, GPT fdisk probably will not notify you of this fact. The reported performance drops for RAID misalignment are lower than those I've observed on disks with 4096-byte sectors, though, and RAID arrays are more likely to be set up by professionals with a good understanding of what they're doing, so I've chosen to err on the side of not annoying or confusing non-RAID users. The ability to override the defaults means that you can adjust alignment as you see fit if you understand the issues involved well enough to optimize alignment for your system.
I've seen some reports that Windows XP has problems with MBR partitions that are not aligned on cylinder (63-sector, typically) boundaries. This isn't ordinarily an issue for GPT disks, of course, but it could be an issue if you use GPT fdisk's ability to create a hybrid MBR or convert a GPT disk to MBR format. I've not yet investigated this matter fully; however, if you intend to create a hybrid MBR, you may want to set your alignment value to 63 or 504 (that is, 63×8, for disks with 4096-byte sectors). Neither value is a power of 2 and so neither will be properly detected when you restart GPT fdisk, however.
Go on to "Converting MBR to GPT"
Return to "GPT fdisk" main page
If you have problems with or comments about this web page, please e-mail me at firstname.lastname@example.org. Thanks.
Return to my main web page.