GUID Partition Table
The GUID Partition Table (GPT) is a standard partitioning scheme for laying out the partition table on disk drives and other block storage devices, which employs 128-bit globally unique identifiers (GUIDs) to define partitions and relies on 64-bit logical block addressing (LBA) to support vast storage capacities.[1] Defined in the Extensible Firmware Interface (EFI) specification version 1.10 and released by Intel on December 1, 2002, GPT was developed as a modern alternative to the legacy Master Boot Record (MBR) partitioning system to address its limitations in handling large disks and multiple partitions.[2] It was subsequently incorporated into the Unified Extensible Firmware Interface (UEFI) specifications starting from version 2.0 in 2006, becoming integral to UEFI-based booting processes.[3] GPT offers significant advantages over MBR, including support for disk sizes up to 264 logical blocks (approximately 9.4 zettabytes, assuming 512-byte sectors), the ability to define up to 128 partitions by default (expandable via software), and enhanced data integrity through primary and backup partition tables located at the disk's beginning and end, respectively.[1] Each partition entry includes a unique GUID for identification, a type GUID specifying its purpose (e.g., EFI System Partition), start and end LBAs, 64-bit attributes for protection and usage flags, and a 36-character Unicode name for human-readable labeling.[1][4] The scheme incorporates CRC32 checksums in both the GPT header and partition entry array to detect corruption, ensuring reliable recovery using the backup structures if the primary fails.[1] For backward compatibility with legacy BIOS systems, GPT disks include a protective MBR at LBA 0 that marks the entire disk as a single invalid partition beyond 2 terabytes.[1] In practice, GPT is the required partition style for UEFI-based installations of modern operating systems, such as Windows 10 and later, where it enables booting from disks larger than 2 terabytes and supports an EFI System Partition formatted as FAT32 (100 MB minimum, 260 MB recommended for 4K sector drives, typically 250–500 MB).[5][6] It also facilitates advanced features like partition alignment to optimize performance on solid-state drives and allows for dynamic resizing without data loss in compatible tools.[7] Widely adopted in enterprise storage, consumer PCs, and servers since the mid-2000s, GPT has become the de facto standard for new systems, particularly those exceeding MBR's 2-terabyte limit per disk.[1][8]History and Development
Origins in UEFI
The GUID Partition Table (GPT) originated as a key component of Intel's Extensible Firmware Interface (EFI) specification, designed to replace the aging Master Boot Record (MBR) partitioning system. Development of GPT began in the early 2000s, with its initial definition appearing in the EFI 1.10 specification released by Intel on December 1, 2002. This effort was led by Intel's engineering team to enable EFI-compliant systems to handle modern storage demands, including bootable disk devices with enhanced partitioning capabilities.[2] The primary motivation for GPT's creation was to address the MBR's inherent constraints, such as its reliance on 32-bit logical block addressing, which limited addressable disk capacity to 2 tebibytes (TiB), and its support for only four primary partitions per disk. By employing 64-bit logical block addressing and GUID-based identifiers for partitions, GPT supported up to 128 primary partitions by default (extensible further) and disk sizes up to 9.4 zettabytes, providing greater scalability and reliability through redundant primary and backup structures with CRC32 integrity checks. Intel's work on GPT was conducted in tandem with the broader EFI framework to facilitate seamless firmware-to-operating-system transitions on Intel platforms.[2] Following Intel's contribution of the EFI specification to the industry, the Unified EFI Forum was established on July 25, 2005, to standardize and advance it. The forum's inaugural UEFI 2.0 specification, released on January 31, 2006, incorporated and formalized GPT as the recommended partitioning scheme for UEFI systems. Significant input during GPT's refinement came from Microsoft to ensure compatibility with Windows, including support starting with Windows Server 2003 for EFI-based booting.[9][3][10] Apple adopted GPT in 2006 for its newly introduced Intel-based Macintosh computers, marking a shift from the proprietary Apple Partition Map to align with EFI/UEFI standards.[11]Evolution and Standards
Following its initial definition within the Extensible Firmware Interface (EFI) framework, the GUID Partition Table (GPT) underwent significant maturation through updates to the Unified Extensible Firmware Interface (UEFI) specification.[12] The UEFI 2.3 specification, released in 2009, introduced enhancements to GPT structures, including improved error handling mechanisms. These updates strengthened GPT's robustness against data corruption during boot processes and disk operations by mandating checksum validation across primary and backup components.[13] Microsoft formally announced support for GPT in 2005 as part of preparations for Windows Vista and subsequent releases, providing native booting and data access on 64-bit UEFI systems, which spurred the development of protective MBR schemes to ensure compatibility with legacy tools.[8] As of 2025, GPT serves as the default partitioning scheme for UEFI booting, with the UEFI Forum's ongoing updates—such as those in the 2.11 specification released in late 2024—enhancing compatibility with NVMe storage devices through dedicated pass-through protocols and accommodating larger sector sizes like 4K native formats via extended block I/O media attributes.[14]Core Concepts and Features
Comparison to MBR
The GUID Partition Table (GPT) represents a significant evolution from the Master Boot Record (MBR) partitioning scheme, addressing key limitations in capacity, flexibility, and reliability for modern storage devices.[1] While the MBR scheme, introduced with early PC BIOS systems, relies on 32-bit Logical Block Addressing (LBA), which restricts disk sizes to a maximum of 2 tebibytes (TiB) assuming 512-byte sectors.[1] Additionally, MBR supports only four primary partitions (or three primary plus one extended partition for logical partitions), and it lacks any built-in redundancy for the partition table, making it vulnerable to corruption and data loss.[1] In contrast, GPT employs 64-bit LBA, enabling theoretical disk sizes up to 9.4 zettabytes (ZB), far exceeding current storage needs.[15] It accommodates up to 128 partitions by default through its partition entry array (expandable based on available space), and includes redundant primary and backup partition tables and headers for enhanced integrity.[1]| Aspect | MBR | GPT |
|---|---|---|
| Addressing Width | 32-bit LBA[1] | 64-bit LBA[1] |
| Maximum Disk Size | 2 TiB[1] | 9.4 ZB[15] |
| Partition Limit | 4 primary (or 3 + extended)[1] | 128 default (expandable)[1] |
| Redundancy | None (single table)[1] | Primary and backup tables/headers[1] |
Key Advantages and Limitations
The GUID Partition Table (GPT) offers enhanced fault tolerance through redundant backup copies of both the primary header and partition entry array, located at the beginning and end of the disk, which allow recovery from corruption in one set by referencing the other.[8][16] This redundancy addresses a key weakness in older schemes like the Master Boot Record (MBR), which lacks such backups and is limited to 2 TiB disk sizes, whereas GPT supports up to 9.4 zettabytes.[15] GPT employs globally unique identifiers (GUIDs) for each partition and disk, ensuring unambiguous identification across multiple drives without the risk of conflicts that can occur in multi-disk configurations using non-unique labels.[8] It also facilitates advanced features, such as the Microsoft Reserved Partition (MSR), which reserves space for system-specific uses like dynamic disk conversions, typically allocating 128 MB on disks of 16 GB or larger.[8] Despite these benefits, GPT requires UEFI firmware for native booting, as legacy BIOS systems cannot directly boot from it and necessitate hybrid configurations with a protective MBR or a dedicated BIOS boot partition.[8][16] This limitation leads to incompatibility with very old hardware, such as 32-bit Windows XP or earlier, which can only access the protective MBR and ignore the GPT structures.[8] Additionally, GPT introduces larger overhead, reserving at least 34 logical block addresses (LBAs) for the primary structures—including the protective MBR (1 LBA), header (1 LBA), and partition entry array (32 LBAs for 128 entries)—reducing usable space on small disks.[1] In practical use cases, GPT excels in environments like servers, RAID arrays, and disks exceeding 2 TiB, where its support for up to 128 partitions by default and vast addressing capacity enable efficient large-scale storage management.[8][16] However, it is less suitable for bootable USB drives in legacy BIOS environments, which often require MBR for broad compatibility.[8] Performance impacts from GPT are minimal, though the inclusion of CRC32 checksums for verifying header and partition integrity adds a slight computational overhead during disk reads and writes to ensure data consistency.[1][8]Disk Layout and Structure
Protective and Hybrid MBR
The GUID Partition Table (GPT) incorporates compatibility mechanisms at the disk's initial sectors to interact with legacy Master Boot Record (MBR) systems, primarily through the Protective MBR and, in specific scenarios, the Hybrid MBR.[1][17] The Protective MBR occupies Logical Block Address (LBA) 0 and consists of a single partition entry of type 0xEE, designated as the GPT Protective partition, which spans the entire disk capacity or up to 2 TiB if the disk is larger.[1][10] This structure, including boot code bytes 0-439 (unused by UEFI), a zeroed disk signature at bytes 440-443, a non-bootable indicator, starting CHS of 0x000200, ending CHS representing the last block or 0xFFFFFF if unrepresentable, starting LBA of 1 (pointing to the GPT header), size in LBAs as the disk size minus one or 0xFFFFFFFF for larger disks, and a signature of 0xAA55 at bytes 510-511, serves to shield the subsequent GPT data structures from modification by GPT-unaware tools or operating systems that assume an MBR layout.[1] By presenting the disk as a single unknown partition, it prevents legacy utilities like MS-DOS FDISK from interpreting the disk as empty or repartitioning it, thereby preserving the integrity of the GPT header at LBA 1 and the partition entries that follow in LBAs 2 through 33.[10][1] In contrast, a Hybrid MBR modifies the Protective MBR by retaining the type 0xEE entry while adding up to three additional primary MBR partitions that map to corresponding GPT partitions, enabling BIOS-based booting on GPT disks in dual-boot environments such as older Windows installations alongside UEFI-aware systems.[17] These additional entries use MBR partition type codes (e.g., 0x07 for NTFS or 0xAF for Apple HFS+) and align with the starting and ending LBAs of selected GPT partitions, typically the first, second, or third, to allow legacy bootloaders to access essential partitions like the system or EFI system partition without recognizing the full GPT structure.[17] Hybrid MBRs are particularly common in setups requiring compatibility with pre-UEFI Windows versions on GPT-formatted disks larger than 2 TiB.[17] Tools such as gdisk (GPT fdisk) facilitate the creation of both Protective and Hybrid MBRs; for instance, gdisk initializes a standard Protective MBR by default on new GPT disks, while entering recovery mode (via the 'r' command) and selecting the hybrid option ('h') allows specification of up to three GPT partition numbers to include in the MBR, followed by writing changes to LBA 0.[17] The fdisk utility from util-linux can also generate basic Protective MBRs during GPT creation, though it lacks native support for hybrid configurations. Following the MBR at LBA 0, LBAs 1 through 33 are reserved for core GPT elements, ensuring no overlap with MBR data.[1] Misconfiguration of Protective or Hybrid MBRs poses significant risks, including data loss from misalignment between MBR and GPT partition boundaries, as GPT-unaware tools may overwrite protective entries or ignore the full disk layout, leading to corruption of GPT metadata.[17] Hybrid MBRs are especially prone to issues, as changes to GPT partitions via unaware utilities can desynchronize the MBR mappings, rendering boot paths unreliable or causing partition table inconsistencies.[17] Experts recommend avoiding Hybrid MBRs when possible, favoring pure GPT with UEFI booting to mitigate these hazards.[17]Primary GPT Header
The Primary GPT Header is a critical data structure in the GUID Partition Table (GPT) layout, located at Logical Block Address (LBA) 1 on the disk, immediately following the protective Master Boot Record (MBR).[1] This header occupies a full 512-byte logical block and serves as the primary metadata descriptor for the disk, defining its overall structure, validation mechanisms, and pointers to other GPT components.[1] It begins with an 8-byte signature "EFI PART" (hexadecimal value 0x5452415020494645) to identify it as an EFI-compatible GPT header.[1] Key fields within the header provide essential disk information and integrity checks. The revision field, a 32-bit unsigned integer at offset 8, specifies the GPT version, with 1.0 (0x00010000) being the standard for UEFI 2.10.[1] The header size field at offset 12, also a 32-bit unsigned integer, indicates the number of bytes used in the header (92 bytes minimum and typical), while the remaining bytes up to 512 are reserved and zero-padded.[1] For self-validation, a 32-bit CRC32 checksum field at offset 16 ensures header integrity; this checksum is computed by setting the CRC32 field to zero and then calculating the CRC32 value over the first 92 bytes (HeaderSize) of the header.[1] The current LBA field (MyLBA) at offset 24, a 64-bit unsigned integer, records the position of this primary header (always 1), and the alternate LBA field (AlternateLBA) at offset 32 points to the backup header's location at the disk's last LBA.[1] The disk GUID, a 128-bit globally unique identifier (16 bytes) at offset 56, uniquely identifies the disk and is generated during formatting to prevent conflicts in multi-disk environments.[1] Details about the partition entry array follow: the starting LBA (PartitionEntryLBA) at offset 72, a 64-bit unsigned integer, typically set to 2; the number of partition entries (NumberOfPartitionEntries) at offset 80, a 32-bit unsigned integer with a default of 128 in many implementations; and the size of each partition entry (SizeOfPartitionEntry) at offset 84, a 32-bit unsigned integer fixed at 128 bytes.[1] A separate CRC32 field at offset 88 validates the entire partition entry array.[1] The following table summarizes the Primary GPT Header's field layout based on the UEFI 2.10 specification:| Offset | Length (bytes) | Field Name | Type | Description |
|---|---|---|---|---|
| 0 | 8 | Signature | ASCII | "EFI PART" (0x5452415020494645) for identification. |
| 8 | 4 | Revision | UINT32 | GPT version, e.g., 1.0 (0x00010000). |
| 12 | 4 | HeaderSize | UINT32 | Size of header in bytes (92 typical). |
| 16 | 4 | HeaderCRC32 | UINT32 | CRC32 checksum of header (self-validating). |
| 20 | 4 | Reserved | UINT32 | Must be zero. |
| 24 | 8 | MyLBA | UINT64 | LBA of this header (1 for primary). |
| 32 | 8 | AlternateLBA | UINT64 | LBA of backup header (disk's last LBA). |
| 40 | 8 | FirstUsableLBA | UINT64 | First logical block address that may be used by a partition for data (typically 34 for 512-byte sectors). |
| 48 | 8 | LastUsableLBA | UINT64 | Last LBA available for partitions. |
| 56 | 16 | DiskGUID | GUID (128-bit) | Unique disk identifier. |
| 72 | 8 | PartitionEntryLBA | UINT64 | Starting LBA of partition entry array (typically 2). |
| 80 | 4 | NumberOfPartitionEntries | UINT32 | Number of entries (default 128). |
| 84 | 4 | SizeOfPartitionEntry | UINT32 | Size per entry (128 bytes). |
| 88 | 4 | PartitionEntryArrayCRC32 | UINT32 | CRC32 of the partition entry array. |
| 92–511 | Variable | Reserved | - | Zero-padded to block size. |
Primary Partition Entries
The primary partition entry array in a GUID Partition Table (GPT) consists of an ordered collection of partition entry structures that define the individual partitions on the disk. This array follows immediately after the primary GPT header and is referenced by thePartitionEntryLBA field in that header, which specifies its starting logical block address (LBA). For disks using 512-byte logical sectors, the array typically occupies LBAs 2 through 33, accommodating up to 128 entries while leaving space for the protective MBR and header.[1]
Each entry in the array is a fixed-size structure of 128 bytes, with the array supporting a default of 128 entries, though the GPT header's NumberOfPartitionEntries field can specify up to 2^64 - 1 entries in theory. Unused entries beyond the last defined partition must be zero-filled to ensure consistency and prevent misinterpretation by disk utilities. The total size of the array is calculated as the product of the number of entries and the entry size (minimum 128 bytes), resulting in a minimum allocation of 16,384 bytes (or 4 KiB when considering aligned sectors, but precisely 16 KiB for 128 entries). This space reservation allows for extensibility, as the entry size can be increased in multiples of 128 bytes (e.g., 128 × 2^n) to support future enhancements without altering the core layout.[1]
The fields within each 128-byte partition entry provide detailed metadata for a single partition, enabling precise disk management. These include:
- Partition Type GUID (bytes 0-15): A 128-bit (16-byte) globally unique identifier (GUID) that specifies the partition's content type, such as a filesystem or reserved space; a zeroed GUID indicates an unused entry.
- Unique Partition GUID (bytes 16-31): Another 128-bit GUID that uniquely identifies the partition across systems, used for referencing in bootloaders and filesystem tools.
- Starting LBA (bytes 32-39): A 64-bit little-endian unsigned integer denoting the first logical block of the partition.
- Ending LBA (bytes 40-47): A 64-bit little-endian unsigned integer specifying the last logical block of the partition, inclusive.
- Attributes (bytes 48-55): A 64-bit bitfield defining partition properties and behaviors (detailed below).
- Partition Name (bytes 56-127): A 72-byte null-padded UTF-16-LE string (up to 36 characters) for a human-readable label.
PartitionEntryArrayCRC32 field. This checksum is computed over the full array size (number of entries × entry size) starting from the array's LBA, using the IEEE 802.3 polynomial. Unlike individual entries, there are no per-entry checksums; any corruption in the array invalidates the header's CRC, prompting recovery from backups. Tools modifying entries must recompute and update this CRC, followed by the header's own CRC.[1]
Backup Structures
The backup GPT header is a redundant copy of the primary GPT header, located at the last logical block address (LBA) of the disk, which is LBA equal to the total number of LBAs minus one.[1] This header mirrors the contents of the primary header at LBA 1, including fields such as the disk GUID, partition entry array LBA, and CRC32 checksums, but with key adjustments: its "My LBA" field points to the last LBA, and its "Alternate LBA" field points to LBA 1 to indicate the primary header's location.[1] These reverse pointers facilitate navigation between the primary and backup structures for validation and recovery purposes.[1] The backup partition entry array is an identical duplicate of the primary partition entry array, containing the same set of up to 128 partition entries (each 128 bytes in size) that describe the disk's partitions, including their GUIDs, starting and ending LBAs, and attributes.[1] This array is positioned immediately after the last usable LBA and before the backup GPT header, spanning a minimum of 16,384 bytes regardless of the underlying sector size.[1] The entries maintain the same sequential order as in the primary array, ensuring consistency without reversal, which allows for straightforward mirroring and integrity checks via CRC32 validation.[1] In the event of corruption to the primary header or entries—such as due to disk errors or incomplete writes—UEFI firmware or partitioning tools can detect the issue through CRC32 checksum failures and switch to the backup structures for recovery.[1] The recovery process involves validating the backup by comparing the disk GUID in both headers; if they match, the backup data is used to rebuild the primary structures, restoring the full partition layout.[1] This redundancy enhances fault tolerance, particularly for large disks where partial failures are more likely.[10] The backup structures collectively occupy the last portion of the disk, typically the final 33 or more LBAs for 512-byte logical sectors (one for the header plus at least 32 for the entry array), leaving any preceding space available for the final partition.[1] For larger sector sizes like 4,096 bytes, the footprint shrinks to about six LBAs (one header plus four for entries), with positions adjusted accordingly via the "First Usable LBA" and "Last Usable LBA" fields in the headers.[1] On very small disks with fewer than 34 LBAs for 512-byte sectors (or equivalent for other sizes), implementing a full GPT layout becomes infeasible, as there is insufficient space to accommodate both primary and backup components without overlap.[1]Partition Identification
GUID Usage
The Globally Unique Identifier (GUID), also known as a Universally Unique Identifier (UUID), is a 128-bit value employed in the GUID Partition Table (GPT) to provide unique identification for both the disk and its individual partitions.[19][20] This format adheres to the structure defined in RFC 4122, consisting of 16 bytes that are typically represented in a canonical textual form as 32 hexadecimal digits grouped into five sequences separated by hyphens: 8-4-4-4-12 (for example, 12345678-1234-1234-1234-123456789ABC).[21] In GPT, all GUIDs follow the EFI GUID conventions, ensuring compatibility with UEFI firmware and operating systems that support the standard.[20] The disk GUID serves as a unique identifier for the entire GPT disk structure and is stored in the primary GPT header at byte offset 56, occupying 16 bytes.[1] It is generated randomly during disk formatting using the version 4 algorithm specified in RFC 4122, which relies on pseudo-random or high-quality random number generation to produce a value compliant with the standard's format and variant bits.[22][20] This random generation ensures the disk GUID remains unique across different systems and storage devices, facilitating reliable disk recognition in multi-disk environments without requiring a central authority.[1] Tools such as gdisk, designed specifically for GPT manipulation, generate fresh random disk GUIDs using secure methods when creating or modifying partition tables. Each partition entry in the GPT includes a unique partition GUID at byte offset 16 within the 128-byte entry structure, spanning 16 bytes.[1] This per-partition identifier is assigned at the time of partition creation and remains associated with that specific partition throughout its lifecycle, enabling precise tracking even if partitions are copied or moved between disks.[1] Operating systems leverage the partition GUID for tasks such as automated mounting— for instance, Linux uses it as the PARTUUID in /etc/fstab configurations to reference partitions independently of device names— and in scripting for volume management and automation.[8][23] The vast namespace of GUIDs, with 2^{128} possible values (approximately 3.4 \times 10^{38}), provides an extremely low probability of collisions, making duplicates negligible in practical scenarios even with widespread generation.[24] Partition tools like GNU Parted and gdisk employ secure random number generators to produce these GUIDs, further minimizing any risk of repetition. Although GUIDs are stored and transmitted in plain text without encryption, their design prioritizes non-sensitive identification rather than confidentiality, rendering them adequate for their intended role in disk and partition management.[19][1]Standard Partition Types
The GUID Partition Table (GPT) employs 128-bit Globally Unique Identifiers (GUIDs) to classify partitions based on their intended contents and usage, enabling operating systems and firmware to recognize and handle them appropriately. These partition type GUIDs are stored in the partition entry array and allow for precise identification without relying on file system signatures alone. While the UEFI specification defines a minimal set of standard types for broad compatibility, most are vendor-specific, reflecting the extensible nature of GPT that avoids the need for a central authority.[1] The following table lists approximately 20 common predefined partition type GUIDs, drawn from the UEFI standard and major operating system vendors. Each entry includes the GUID, a descriptive name, and a brief explanation of its purpose. These examples illustrate the diversity of types for boot, data, and system partitions across platforms.| GUID | Name | Description |
|---|---|---|
| 00000000-0000-0000-0000-000000000000 | Unused Entry | Marks an unused or free partition entry in the GPT table.[1] |
| C12A7328-F81F-11D2-BA4B-00A0C93EC93B | EFI System Partition | Contains UEFI boot loaders, drivers, and utilities; formatted as FAT32.[1] |
| 024DEE41-33E7-11D3-9D69-0008C781F39F | Legacy MBR | Indicates a partition compatible with legacy Master Boot Record (MBR) schemes.[1] |
| EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 | Microsoft Basic Data | General-purpose data partition used by Windows for file storage, typically NTFS-formatted.[4] |
| E3C9E316-0B5C-4DB8-817D-F92DF00215AE | Microsoft Reserved | Reserved space on GPT disks for Windows partition management; not formatted or mountable.[25] |
| DE94BBA4-06D1-4D40-A16A-BFD50179D6AC | Windows Recovery Environment | Stores tools for Windows Recovery Environment (WinRE), such as startup repair utilities.[5] |
| 0FC63DAF-8483-4772-8E79-3D69D8477DE4 | Linux Filesystem Data | Generic type for Linux data partitions, supporting file systems like ext4 or XFS.[26] |
| 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F | Linux Swap | Dedicated swap space for virtual memory in Linux systems.[26] |
| 4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709 | Linux Root (x86-64) | Discoverable root partition (/) for 64-bit x86 Linux installations.[26] |
| 933AC7E1-2EB4-4F13-B844-0E14E2AEF915 | Linux /home | Discoverable partition for user home directories in Linux.[26] |
| 3B8F8425-20E0-4F3B-907F-1A25A76F98E8 | Linux /srv | Discoverable partition for server data in Linux environments.[26] |
| 21686148-6449-6E6F-744E-656564454649 | BIOS Boot Partition | Unformatted space for GRUB bootloader on BIOS/GPT hybrid systems.[27] |
| 48465300-0000-11AA-AA11-00306543ECAC | Apple HFS+ | Hierarchical File System Plus partition used in older macOS installations.[28] |
| 7C3457EF-0000-11AA-AA11-00306543ECAC | Apple APFS Container | Container for Apple File System volumes in modern macOS.[28] |
| E6D6D379-F507-44C2-A23C-238F2A3DF928 | Linux LVM | Logical Volume Manager partition for dynamic storage in Linux.[29] |
| AF9B60A0-1431-4F62-BC68-3311714A69AD | Microsoft LDM Data | Data partition on dynamic disks using Logical Disk Manager (LDM).[4] |
| 5808C8AA-7E8F-42E0-85D2-E1E90434CFB3 | Microsoft LDM Metadata | Metadata partition for Logical Disk Manager on dynamic Windows disks.[25] |
| AF9B60A0-1431-40B8-A267-2817BE8F6B63 | Apple Core Storage | Used for Fusion Drive or logical volume groups in macOS.[28] |
| 9F4F4E3D-0000-11AA-AA11-00306543ECAC | Apple UFS | Unix File System partition used in legacy Apple systems.[30] |
| FE3A2A5D-4F32-41A7-B725-ACCC3285A309 | Chrome OS Kernel | Partition for Chrome OS kernel images.[31] |
| CA7D7CCB-63ED-4C53-8615-17E458844511 | Linux LUKS | Encrypted partition using Linux Unified Key Setup (LUKS).[26] |
Operating System Support
Unix-like Systems
Unix-like systems have provided robust support for the GUID Partition Table (GPT) since the mid-2000s, enabling efficient management of large-capacity disks across various distributions and variants. In Linux, the kernel has included native GPT support since version 2.6, allowing for the recognition and utilization of GPT-structured disks without additional modules.[32] This integration facilitates the handling of disk sizes exceeding 2 TiB, leveraging 64-bit logical block addressing (LBA) to address sectors beyond the limitations of older MBR schemes. Tools such asfdisk (from util-linux) support GPT creation and manipulation alongside MBR, while parted offers advanced partitioning capabilities including resizing and alignment for GPT layouts.[33][34] Specialized utilities like gdisk (part of GPT fdisk) provide GPT-specific operations, such as converting MBR to GPT and verifying partition integrity, and libblkid enables GUID detection for automated filesystem identification.
FreeBSD introduced GPT support in version 7.0-RELEASE in 2008, marking a shift toward modern partitioning for larger drives and UEFI booting compatibility.[35] The gpart utility serves as the primary tool for creating, modifying, and bootstrapping GPT partitions on GEOM providers, supporting schemes like GPT alongside legacy formats.[36] In illumos-based systems such as OpenIndiana and OmniOS (derived from Solaris), GPT is managed through the format command and fdisk, which handle EFI-labeled disks and allow partitioning up to 128 slices, though typically limited to seven usable partitions for compatibility.[37][38] These tools ensure seamless integration with ZFS pools and other filesystems on GPT disks.
macOS, as a Unix-like derivative, has used GPT as the default partitioning scheme since Mac OS X 10.4 Tiger (2005) for Intel-based systems, with full booting support on EFI hardware.[39] The Disk Utility application provides a graphical interface for GPT operations, including formatting, partitioning, and conversion to schemes like APFS, which employs specific GUIDs for container volumes (e.g., the APFS Container Scheme GUID).[40]
Across these systems, common features include support for 4K native sectors to optimize performance on advanced storage devices, integration with software RAID (e.g., mdadm on Linux for assembling arrays on GPT partitions), and booting mechanisms like GRUB2 for Linux (which embeds GPT-aware modules) or OpenFirmware on PowerPC-based macOS variants.[41]) However, limitations persist in older configurations: pre-2.6 Linux kernels may lack full 64-bit LBA support, restricting GPT functionality to 32-bit addressing and thus capping usable disk space at around 2 TiB.[32] Additionally, ZFS on Linux requires GPT partitioning for pools exceeding 2 TiB to avoid MBR size constraints during vdev creation.[42]