Partition type
In computing, a partition type is an identifier encoded in a disk's partition table to denote the intended format, file system, or usage of a specific partition, enabling operating systems and bootloaders to recognize and handle it appropriately.[1] These types are essential for organizing storage on hard drives, solid-state drives, and other block devices, allowing multiple logical divisions on a single physical disk while maintaining compatibility across systems.[2] The two dominant partitioning schemes differ significantly in how they represent partition types. The older Master Boot Record (MBR) scheme, introduced with early PC BIOS systems, limits disks to a maximum of four primary partitions (or three primary plus one extended partition containing logical ones) and uses a single-byte hexadecimal code (ranging from 0x00 to 0xFF) in each partition entry to specify the type.[1] Common MBR types include 0x07 for Windows NTFS, 0x0B for FAT32, 0x83 for Linux native partitions (such as ext2, ext3, or ext4), and 0x82 for Linux swap space, with the scheme supporting disks up to 2 TiB in size using 512-byte sectors.[3][1] In contrast, the GUID Partition Table (GPT), standardized as part of the UEFI firmware specification, replaces the byte code with a 128-bit Globally Unique Identifier (GUID) for each partition type, supporting up to 128 partitions by default (expandable) and disk sizes up to 8 ZiB.[4] Standard GPT types include the GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B for the EFI System Partition (used for booting UEFI systems) and DE94BBA4-06D1-4D40-A16A-BFD50179D6AC for Microsoft Reserved partitions.[1] GPT also incorporates redundancy with primary and backup partition tables, enhancing data integrity against corruption.[4] Partition types play a critical role in system configuration, installation, and maintenance; for instance, mismatched types can prevent operating systems from mounting or booting from a partition, and tools likefdisk or gdisk are used to view and modify them.[1] While MBR remains in use for legacy compatibility, GPT has become the preferred standard for modern systems due to its scalability and support for advanced features like secure boot.[2]
Fundamentals
Definition and Role in Disk Management
A partition type is a numeric or alphanumeric code assigned to a disk partition to indicate its intended use, such as hosting an operating system, a specific filesystem, or diagnostic tools.[5] These codes, often represented in hexadecimal format, serve as identifiers that inform software about the partition's purpose and compatible handling methods.[6] In disk management, partition types play a crucial role by enabling bootloaders, operating systems, and partitioning utilities to recognize and interact with partitions correctly. For instance, they guide the mounting of filesystems, allocation of resources, and execution of boot processes, ensuring that tools apply the appropriate protocols without attempting incompatible operations.[5] This recognition is facilitated through entries in partition tables, where the type code is recorded alongside other partition metadata.[7] The importance of partition types lies in maintaining compatibility across diverse hardware and software environments, where incorrect assignment can result in boot failures, inaccessible data, or unintended data corruption during read/write operations.[6] By accurately signaling the partition's role, these types prevent misconfigurations that could otherwise lead to system instability or loss of access to critical storage areas.[5] As a basic example, the hexadecimal code 0x83 designates a standard Linux filesystem partition, allowing Linux-based systems to identify and mount it natively for data storage.[7]Partition Tables and Type Identification
Partition tables serve as essential data structures on storage devices, typically beginning at logical block address (LBA) 0, that organize the disk into logical partitions by specifying their locations, sizes, and associated metadata. This metadata includes a type identifier for each partition, which indicates its purpose, such as hosting an operating system or serving as a data container, enabling the operating system and tools to interpret and manage the storage appropriately. These tables ensure that the disk's capacity is divided efficiently while maintaining compatibility across different hardware and software environments.[4][8] The Master Boot Record (MBR) represents the traditional partition table format, occupying a fixed 512-byte sector at the disk's start. It comprises 446 bytes of executable boot code, a 64-byte partition table that accommodates up to four primary partition entries, and a 2-byte boot signature (0xAA55) for validation. Each 16-byte partition entry within the table includes fields for status, starting and ending heads/sectors/cylinders (legacy addressing), sector counts, and crucially, a 1-byte hexadecimal field at offset 0x04 that encodes the partition type. This compact structure supports basic disk partitioning but limits addressable storage to 2 tebibytes due to 32-bit sector addressing.[9][10][11] In contrast, the GUID Partition Table (GPT), introduced as part of the Unified Extensible Firmware Interface (UEFI) standard, employs a more robust and scalable design to address MBR's limitations. GPT begins with a protective MBR at LBA 0, which mimics an MBR entry to shield the table from legacy tools, followed by the primary GPT header at LBA 1. This header, at least 92 bytes in size, includes fields like the disk GUID, pointers to partition entries, and checksums for integrity. The partition entries form an array (typically starting at LBA 2), with each 128-byte entry featuring a 128-bit PartitionTypeGUID field to uniquely specify the partition's role, alongside attributes, unique GUIDs, and LBA ranges. A redundant backup header and entry array at the disk's end enhance data reliability against corruption.[4] Partition type identification occurs through disk management utilities that parse these tables to extract and interpret the type fields. For instance, the fdisk utility reads the MBR from sector 0 or the GPT header from LBA 1, then decodes the respective type indicators—1-byte values for MBR or 128-bit GUIDs for GPT—to list, classify, and operate on partitions during tasks like formatting, resizing, or mounting filesystems. Similarly, gdisk specializes in GPT by directly accessing the header and entry array to display types and facilitate edits. These tools ensure that the type metadata guides subsequent actions, such as selecting appropriate filesystem drivers.[12][13] Compatibility between partition tables and firmware modes is critical for booting and system operation. Legacy BIOS firmware, common in older x86 systems, natively processes MBR tables and relies on the 1-byte type codes to locate bootable partitions during the boot process. Modern UEFI firmware, however, is optimized for GPT, using the GUID-based types to identify and load bootloaders from specific partitions, such as the EFI System Partition, while providing enhanced security features like Secure Boot. UEFI systems can enable Compatibility Support Module (CSM) to emulate legacy BIOS behavior for MBR disks, but direct GPT support in UEFI mode is preferred for larger disks and improved robustness.[14][15]Historical Evolution
Master Boot Record (MBR) System
The Master Boot Record (MBR) partitioning system originated in 1983 alongside PC DOS 2.0, establishing the initial standardized method for dividing hard disk drives into partitions on IBM PC-compatible computers.[16] This scheme quickly became the de facto standard for early personal computing, enabling the organization of storage space for operating systems like MS-DOS and facilitating boot processes through BIOS firmware.[16] Its design reflected the hardware constraints of the era, prioritizing simplicity and compatibility with 512-byte sectors on fixed disks. At its core, the MBR occupies the first sector (sector 0) of a disk, comprising 446 bytes of boot code, followed by a 64-byte partition table spanning bytes 446 to 509, and ending with a 2-byte boot signature (0x55AA).[17] The partition table consists of up to four 16-byte entries, where the fourth byte of each entry defines the partition type ID—a hexadecimal value indicating the intended use or filesystem, such as 0x00 for unused space or 0x05 for an extended partition that chains to additional logical partitions.[17] This structure allows the boot code to locate and load the volume boot record from the active primary partition during system startup. Despite its foundational role, the MBR system imposes significant constraints, limiting disks to four primary partitions (or three primaries plus one extended partition containing logical ones) and capping addressable storage at 2 TiB due to reliance on 32-bit logical block addressing (LBA).[18] These limitations stem from the original CHS (cylinder-head-sector) addressing scheme's evolution to LBA, which could not scale beyond 2^32 sectors of 512 bytes without modifications incompatible with legacy hardware.[18] Early MBR partition types centered on FAT filesystems, with 0x01 designating FAT12 or FAT16 volumes suitable for small disks, and 0x06 for larger FAT16 partitions exceeding 32 MB.[3] These codes, introduced in the MS-DOS era, evolved through subsequent Windows releases, which standardized 0x07 for NTFS and retained FAT variants for compatibility, while Linux adoption introduced codes like 0x83 for ext2/ext3 filesystems within the same MBR framework.[3] This incremental expansion supported cross-platform use but highlighted the scheme's rigidity compared to emerging alternatives. Since the widespread adoption of the GUID Partition Table (GPT) around 2010, coinciding with UEFI firmware in Windows 7 and later, the MBR has been progressively deprecated for new systems due to its scalability issues. Nonetheless, as of 2025, MBR persists in legacy BIOS-based environments, embedded devices, and older installations where compatibility with pre-UEFI hardware remains essential.GUID Partition Table (GPT) Development
The GUID Partition Table (GPT) was introduced as part of the Extensible Firmware Interface (EFI) specification developed by Intel in the early 2000s, specifically for the Itanium (IA-64) platform to address the limitations of the Master Boot Record (MBR) system, including its 2 TiB disk size cap due to 32-bit logical block addressing and restriction to four primary partitions without extended structures.[19] It was subsequently incorporated into the Unified Extensible Firmware Interface (UEFI) specification, version 2.0, first released on January 31, 2006, by the UEFI Forum (formed in 2005) to extend and unify the EFI across platforms.[4] By introducing a more scalable and robust partitioning scheme, GPT enabled support for modern large-capacity storage devices and simplified partition management in UEFI environments. GPT's structure features a primary header located at logical block address (LBA) 1 and a backup header at the disk's last LBA, with the partition entry array following the primary header starting at LBA 2.[4] The standard layout reserves space for 128 partition entries, each 128 bytes long, allowing up to 128 partitions by default, though this can be extended by increasing the entry array size.[20] Each partition is identified by a 128-bit universally unique identifier (UUID), known as a GUID, which specifies its type; for instance, the GUID EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 denotes a Microsoft basic data partition.[21] Key advantages of GPT include its use of 64-bit LBAs, supporting disk sizes up to 8 ZiB (9.44 zettabytes) with 512-byte sectors or 64 ZiB (75.5 zettabytes) with 4,096-byte sectors, far exceeding MBR's constraints.[4] It incorporates CRC32 checksums in both headers and partition entries to detect corruption and ensure data integrity, with the backup structures allowing recovery if the primary ones fail.[4] Additionally, GPT supports hybrid MBR configurations at LBA 0, enabling compatibility with legacy BIOS booting on GPT-formatted disks while protecting against accidental overwriting.[21] Adoption of GPT accelerated with the release of Windows 8 in 2012, which mandated GPT for UEFI-based installations to leverage Secure Boot and larger drives.[20] macOS has utilized GPT as the default partitioning scheme since the transition to Intel processors in 2006, aligning with its EFI implementation that evolved into UEFI support.[22] By the 2020s, GPT became the standard for UEFI booting across major operating systems, driven by the ubiquity of UEFI firmware in consumer and enterprise hardware. As of 2025, GPT dominates partitioning on new hardware, including SSDs and HDDs exceeding 2 TiB, due to its alignment with UEFI and support for advanced features like NVMe storage.[23] Tools such as GNU Parted facilitate non-destructive conversions from MBR to GPT, preserving data while enabling upgrades to UEFI systems.Standard Partition Types
Operating System-Specific Types
Operating system-specific partition types are predefined identifiers in both Master Boot Record (MBR) and GUID Partition Table (GPT) schemes that signal to bootloaders and operating systems the intended use of a partition for installation, booting, or primary storage. These types ensure compatibility during the boot process, where the firmware or bootloader scans for recognizable identifiers to load the appropriate OS loader or kernel. For instance, in MBR, the type is a single byte (e.g., 0x07), while in GPT, it is a 128-bit GUID that provides more granular identification.[8][11] Microsoft Windows primarily uses the NTFS filesystem for its system partitions, identified by MBR type 0x07, which denotes an installable filesystem partition compatible with Windows NT and later versions. This type allows the Windows bootloader to recognize and mount the partition during boot, supporting up to 2 TB in MBR limits. In GPT configurations, the EFI System Partition (ESP) uses the GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B and is formatted as FAT32 to store boot files for UEFI firmware, enabling secure boot and compatibility with drives larger than 2 TB. Additionally, the Microsoft Reserved Partition (MSR) employs the GUID E3C9E316-0B5C-4DB8-817D-F92DF00215AE, a small unformatted space required on every GPT disk for future use by the OS, typically 16 MB in size, which the Windows installer automatically creates to maintain partition alignment.[24][20][20] Linux distributions commonly designate MBR type 0x83 for native Linux filesystems such as ext2, ext3, or ext4, indicating a primary partition suitable for the root filesystem or boot files, which the kernel and bootloaders like GRUB can mount directly. This type triggers GRUB to probe for a Linux kernel and initramfs during the boot sequence, supporting legacy BIOS booting on disks up to 2 TB. For GPT, the Linux filesystem GUID 0FC63DAF-8483-4772-8E79-3D69D8477DE4 is used for general-purpose data partitions, allowing the bootloader to identify and access ext4 or similar filesystems for loading the OS, with GRUB recognizing this GUID to locate kernel images and initiate the boot process on UEFI systems. GRUB's configuration scans partitions with these types to generate boot entries, ensuring seamless multi-boot support.[11][25][26] macOS employs MBR type 0xAF for Apple HFS or HFS+ partitions, marking areas intended for the macOS system volume, which the Darwin bootloader uses to locate boot files and the kernel on legacy setups. This type ensures compatibility with hybrid MBR/GPT disks common in Intel-based Macs. In GPT, the Apple HFS+ GUID 48465300-0000-11AA-AA11-00306543ECAC identifies partitions formatted with HFS+. For APFS, the successor filesystem introduced in macOS High Sierra (10.13) in 2017, the GUID is 7C3457EF-0000-11AA-AA11-00306543ECAC, enabling the EFI bootloader to mount the volume and load macOS during UEFI boot, with the partition typically serving as the root for the entire OS installation.[27][28] Other operating systems include FreeBSD, which uses MBR type 0xA5 for its UFS filesystem partitions, signaling to the FreeBSD bootloader the presence of bootable slices containing the kernel and loader code for BIOS-based systems. The related type 0xA6 is for OpenBSD compatibility in multi-OS environments. For GPT, FreeBSD utilizes the GUID 516E7CB4-6ECF-11D6-8FF8-00022D09712B to denote UFS or ZFS partitions, allowing the loader to recognize and boot from UEFI firmware by accessing the designated root filesystem.[29][30] Solaris (now Oracle Solaris) designates MBR type 0xBF for its system partitions, an updated identifier from the earlier 0x82, used to mark areas for UFS or ZFS filesystems that the Solaris bootloader can mount during x86 BIOS boot, supporting installations on MBR disks with up to four primary partitions. This type ensures the GRUB-like bootloader or direct kernel loading identifies the Solaris root for initialization. Solaris also supports GPT, using GUID 6A85CF4D-1DD2-11B2-99A6-080020736631 for the root partition.[31][32]Filesystem and Utility Types
Partition types for filesystems specify the format of data storage on a disk partition, allowing operating systems to detect and mount the appropriate filesystem driver for access. These types are essential for data integrity and interoperability, as they guide tools like fdisk or gdisk in identifying partition contents without probing the actual data. In the Master Boot Record (MBR) scheme, types are represented by a single hexadecimal byte, providing a simple but limited classification. Conversely, the GUID Partition Table (GPT) employs 128-bit globally unique identifiers (GUIDs) for greater specificity and scalability, as defined in the UEFI specification.[4] Common filesystem types include the FAT family, widely used for compatibility across devices; NTFS and exFAT for Windows environments; and ext4 and Btrfs for Unix-like systems. The following table summarizes representative codes for these filesystems in both MBR and GPT formats:| Filesystem Family | Specific Variant | MBR Type Code | GPT GUID |
|---|---|---|---|
| FAT | FAT12 | 0x01 | EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data)[21] |
| FAT | FAT32 | 0x0B | EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data)[21] |
| NTFS/exFAT | NTFS | 0x07 | EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data)[21] |
| NTFS/exFAT | exFAT | 0x07 | EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data) |
| Unix-like | ext4 | 0x83 | 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)[33] |
| Unix-like | Btrfs | 0x83 | 91280000-11A3-4D07-807D-A1F14AB9E9A5 (Btrfs)[34] |