Last Web page update: 4/18/2022, referencing GPT fdisk version 1.0.9
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 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 1 MiB. At worst, it'll consume a small amount of disk space.
In the past, MBR disks often used partitions that began only on sectors that are multiples of 63. This was 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. Most modern MBR partitioning tools 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. Beginning with version 0.7.1, GPT fdisk 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.
Beginning with version 1.0.9, GPT fdisk also aligns partitions' sizes. The reson has nothing to do with performance, though; it's to prevent problems with the LUKS2 disk encryption tools, which require that partitions be sized to match the encryption block size, which is normally either 512 bytes or 4096 bytes. When you specify a partition size in MiB or larger units, the partition-size end-alignment is automatic. It's only the last partition that might be affected by this policy, which is automatic in gdisk and cgdisk but must be activated by the new -I/--align-end option to sgdisk. You can override the feature by specifying an exact end sector in sgdisk, including by copying the end sector specified on the prompt line that shows the valid end sector values.
The EFI specification is mute on the subject of the size of the ESP. As noted earlier, Apple recommends a 200 MiB ESP. Furthermore, Microsoft used to create 100 MiB ESPs, although I believe they've increased this default size more recently. Such small ESPs may not be optimal, though. A number of factors interact on this issue, including:
Combining these issues, I generally recommend creating an ESP that's at least 550 MiB in size. Although 512 MiB is large enough to avoid most problems, the potential for MB-MiB confusion makes me recommend something that will be large enough even if the person taking my advice uses a tool that specifies partition sizes in MB rather than MiB. (GPT fdisk uses MiB when you specify a disk size as +###M.) Because 537 is a strange number to remember, I round up to 550 MiB. This is a peculiar number, but it's easy to remember, and it's safe from ESP FAT filesystem bugs.
In some cases, a larger ESP may be beneficial. Some users like to store their Linux kernels on the ESP. This placement conforms to the systemd Boot Loader Specification, which advocates storing kernels in specific directories on the ESP as a way to help boot loaders that lack the ability to read native Linux filesystems, and to help multi-Linux configurations coexist. If you want to do this, and especially if you want to install multiple distributions, having a large ESP may be necessary.
An EFI-bootable computer needs one ESP. In most cases, this ESP is shared between all the OSes installed on the computer. Thus, ESPs are not strictly necessary on secondary hard disks, although Apple advises that they be present on most disks, as noted earlier. Placing an ESP on each disk will enable you to convert it into a bootable disk (that is, one that holds EFI boot loaders) should the need arise.
It's possible to create multiple ESPs on a single hard disk, but as a general rule, this is inadvisable because it can be confusing. That said, some people like to do this so as to isolate different OSes' boot loaders from each other. In my experience, this practice is more likely to create than to solve problems, but there can be exceptions to this rule. For instance, multiple ESPs can isolate two Windows versions' boot loaders from one another, so that each Windows installation can have its own entry in another boot manager, such as GRUB 2 or rEFInd. This is definitely an advanced configuration option, though.
Go on to "Converting MBR to GPT"
Return to "GPT fdisk" main page
copyright © 2009–2022 by Roderick W. Smith
If you have problems with or comments about this web page, please e-mail me at rodsmith@rodsbooks.com. Thanks.
Return to my main web page.