What's a GPT?

by Rod Smith, rodsmith@rodsbooks.com

Last revision: 1/28/2010, GPT fdisk version 0.6.2

In order to understand what GPT is, you must first understand the current standard for disk partitioning and its limits. With that knowledge in hand, you can see how GPT can fix MBR's deficiencies.

MBR, Its Annoyances, and Its Limits

Since the earliest hard disks for x86 computers, these disks have been divided into one or more partitions using a partitioning scheme that has, through the ages, gone by several names, such as MS-DOS disklabels, BIOS partitions, and MBR partitions. By whatever name, the MBR partitioning scheme has several characteristics that have, in one way or another, been limitations or annoyances:

• The MBR system originally provided for only four partitions. As a workaround, one of these original (or primary) partitions can be set aside (and is then known as an extended partition) to hold an arbitrary number of logical partitions. This configuration is awkward and can lead to problems, since some OSes can only boot from primary partitions and since it's not easy to convert a partition from one type to another.
• MBR partitions include one-byte partition type codes to help OSes identify the partitions' purpose. The single byte has proven somewhat limiting, and there are occasional collisions—a single code with an ambiguous meaning, such as 0x82, which can refer to either Linux swap space or a Solaris disklabel.
• The MBR scheme originally employed cylinder/head/sector (CHS) addresses to identify partitions' locations. This feature can lead to problems because different BIOSes or OSes can interpret the CHS geometry in different ways. The CHS scheme also tops out at a maximum disk size of 8 GiB. In part to work around this limitation, MBR has been extended to use 32-bit logical block addressing (LBA), but using both systems itself introduces the opportunity for problems, such as mismatched CHS and LBA definitions for a single partition. In practice, modern OSes seem to mostly ignore the CHS values, and they must ignore the CHS values on partitions that begin or end beyond the 8 GiB mark.
• In conjunction with the near-universal sector size of 512 bytes, the 32-bit LBA pointers used by MBR partitions impose a 2 TiB limit on disk and partition size. This limit, unlike the earlier 8 GiB limit of CHS, is not easily overcome by a simple extension to MBR; there simply isn't space left in the size allocated to MBR data structures. With 2 TiB drives available now and larger drives expected soon, this problem is a very serious one. (Certain types of hardware RAID configurations permit virtual drive sizes to exceed 2 TiB even today.)
• MBR partitions are susceptible to damage. The primary partition table is stored entirely within the first sector of the disk, so if it's destroyed or damaged, it will be hard to recover the disk's partitions. Logical partitions are stored in a linked list data structure that's scattered over the extended partition, so if a single link is broken, access to the remaining logical partitions will be lost.

Four for the Price of Two?

If you're familiar with MBR data structures, you may think I'm being a little bit pessimistic. This is because MBR records partition locations in terms of the starting sector and the partition's length. Both of these are 32-bit values, so in theory you could use MBR on a 4 TiB disk, so long as all the space after the 2 TiB mark is in a single primary partition, or perhaps in a single extended partition, which could in turn hold many logical partitions. Such a configuration would be somewhat limiting, but it fits within the MBR framework.

To test the practicality of such a configuration, I ran tests using the QEMU machine emulator and its virtual disks, which can appear much larger to a guest OS than to the host OS. I was able to create a 4 TiB disk that was just kilobytes in size on my real disk (although it grew as I manipulated it, of course). I tested with a number of legacy and modern OSes, including Linux, FreeBSD, Windows Me, Windows XP, OS/2, and BeOS.

To make a long story short, the only OSes that seemed capable of handling a partition that spanned the 2 TiB mark were Linux and FreeBSD. Windows Me didn't show a drive icon, and its FDISK reported that it was unable to access the disk. Windows XP saw the disk as being just 8 GiB in size. BeOS reported the disk information correctly in its disk setup tool, but was unable to mount the partition I created in Linux or to create a new filesystem on the partition. OS/2's FDISK reported the already-created partition was smaller than it was; apparently it just ignored everything past the 2 TiB mark. One caveat: It's conceivable that these OSes were interacting with a peculiarity of the QEMU environment to create these problems; however, as Linux and FreeBSD were able to handle the disks, I suspect the real problem was in the OSes themselves.

Because Linux and FreeBSD have relatively mature GPT support, there seems to be limited benefit to carefully crafting a configuration to enable use of MBR on a 2-4 TiB drive—at least, for the OSes I tested. I was unable to test Windows Vista or Windows 7 in QEMU, and it's conceivable that one or both of them would benefit from such a configuration. Overall, though, I consider 2 TiB to be the practical limit for MBR, since so many OSes can't use MBR's theoretical capacity to manage some configurations of up to twice that size.

GPT to the Rescue

The heir apparent to MBR is GPT. This new partitioning scheme fixes many of MBR's problems:

• In its most common configuration, GPT supports up to 128 partitions, so there's no need for extended or logical partitions. In case needs change, GPT data structures permit larger partition table sizes, although in practice few tools seem to allow users to adjust this parameter. (GPT fdisk does, though.)
• The GPT partition type code is a 128-bit (16-byte) GUID. In theory, this gives plenty of room for lots of unique partition types. Unfortunately, in practice there are already collisions—most importantly for Linux users, Linux and Windows use the same type code for their data partitions. To supplement the type code, GPT supports a plain-text name for each partition.
• GPT knows nothing about CHS geometries and it uses 64-bit sector pointers, so 2 TiB drives are puny compared to the total supported disk size of GPT.
• GPT adds CRC32 checksums to its data structures and stores those structures twice on the disk—once at the start of the disk and again at the end. These measures help protect the system against accidental damage caused by carelessness or disk errors.

Unfortunately, GPT is not without its problems. These mainly relate to compatibility. Older OSes have no or limited GPT support. For instance, Windows only supports GPT at all on Windows Server 2003, the 64-bit (but not the 32-bit) version of Windows XP, Windows Vista, and later. Through Windows 7, booting from a GPT disk is impossible unless the system uses the Extensible Firmware Interface (EFI) rather than a legacy BIOS. (Most computers through at least September of 2009 still use a legacy BIOS. All Intel-based Macintoshes use EFI, though, and EFI is starting to appear as a user-configurable option on some mainstream motherboards.) Linux has long supported GPT, but boot support depends on the boot loader. GRUB through version 0.97 doesn't officially support booting from GPT, but patched versions of GRUB 0.97 with GPT support are common, and GRUB2 officially supports booting from GPT. Intel-based Macs use GPT by default. (The "Booting from GPT" section of this Web page describes GPT boot issues in more detail.)

To protect GPT disks against errant older disk tools, GPT keeps an MBR partition table on the first sector of the disk. This MBR contains a single disk-spanning partition of type 0xEE, which makes older tools think the disk is in use by an unknown OS. Some tools take advantage of this feature to create a hybrid MBR configuration, in which some partitions are accessible via both GPT and MBR definitions. Although this is non-standard, awkward, and delicate, it can help make the transition from MBR to GPT easier by providing a workaround for OSes that don't understand GPT.

In addition to the protective MBR, GPT features two main types of data structure, each of which is stored on the disk twice:

• The GPT headers contain disk meta-data—information on the locations of the partition tables, the disk GUID, and so on. No actual partitions are defined in the headers, though. Each disk has two headers, a main header and a backup header. If one is damaged, you can use the other to recover the damaged one.
• Just as there are two headers, there are two partition tables. These should be byte-for-byte identical to one another, unlike the headers, which vary because they need to point to each other and to their own partition tables.

Because of the hard 2 TiB limit of MBR partitions, chances are you'll be forced to switch to GPT for at least some disks in the not-too-distant future. MBR is likely to remain useful on smaller devices, such as USB flash drives, for years to come. In 2010, most x86 and x86-64 PCs still use MBR-partitioned disks. Mac hardware is an exception to this rule; Apple has embraced GPT, as well as the EFI, of which the GPT definition is part.

Go on to "Why Use GPT fdisk?"

Return to "GPT fdisk" main page

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.