What is a GUID Partition Table (GPT) Disk? - A Comprehensive Guide

The GUID Partition Table (GPT) disk architecture stands as a modern standard, introduced as part of the Extensible Firmware Interface (EFI) initiative. GPT serves as a significant evolution from the older Master Boot Record (MBR) partitioning scheme, which has been a long-standing norm in Intel-based computers. Understanding GPT is crucial in today’s computing landscape, especially with the increasing demand for larger storage capacities and more flexible partitioning.

A partition, in essence, is a continuous segment of storage space on either a physical or logical disk. It operates as if it were an independent, physically separate disk. These partitions are recognized by the system firmware and the operating systems installed, and access to them is managed by the active system firmware and operating system.

Why is the GUID Partition Table Necessary?

GPT disks are essential for several key reasons, primarily addressing the limitations of the older MBR system:

Addressing Size Limitations: MBR disks have a critical limitation in addressable storage space, effectively capping disk sizes at 2TB. GPT overcomes this barrier, supporting dramatically larger disk sizes. As of July 2001, Microsoft’s implementation already supported hard disks up to 18 EB (Exabytes) using 512KB Logical Block Addresses (LBAs). This vast capacity is crucial for modern storage demands.

Increased Partition Flexibility: MBR’s partitioning scheme is restrictive, allowing only four primary partitions or a combination of primary and logical partitions within an extended partition. GPT removes this constraint. While Microsoft’s implementation limits GPT disks to 128 partitions, this is a significant increase in practical terms and is not burdened by the older “container partition” workarounds of MBR. It’s worth noting that in a typical Windows GPT setup, a few partitions are reserved for system functions (EFI System Partition, Microsoft Reserved Partition, and potentially dynamic disk partitions), leaving a substantial number (e.g., 124) available for data.

Improved Data Integrity and Redundancy: GPT’s design emphasizes robustness and data integrity. Crucial operating system data is stored within partitions, not in unpartitioned or hidden sectors, eliminating the ambiguity and risks associated with hidden sectors in MBR. GPT utilizes primary and backup partition tables for redundancy, enhancing fault tolerance. It also employs CRC32 checksums to ensure the integrity of the partition data structure. Furthermore, GPT’s format includes version numbers and size fields, allowing for future expansion and adaptability.

Unique Identification and Naming: Each GPT partition is assigned a globally unique identifier (GUID) and a partition content type GUID. This eliminates the possibility of identifier collisions, a problem inherent in MBR’s two-byte partition identifiers. GPT also allows for 36-character Unicode names for partitions, enabling software to display user-friendly, easily understandable partition names without needing to interpret complex partitioning schemes.

What are the Drawbacks of MBR Partitioning?

MBR partitioning, while historically significant, suffers from several limitations that GPT effectively resolves:

Partition Limits: MBR’s restriction to four primary partitions is a major constraint. While extended partitions and logical drives were introduced as a workaround, they add complexity and limitations.

Cylinder Alignment Issues: MBR partitions and logical drives must be cylinder-aligned, even on advanced hardware RAID systems that abstract the underlying physical geometry. This requirement can lead to inefficiencies and complexities in disk management.

Poorly Defined and Complex Rules: MBR partitioning rules are often vaguely defined and intricate. The concept of “cylinder alignment” itself is ambiguous (e.g., minimum partition size in cylinders). MBR partition identification relies on a two-byte field, requiring coordination to prevent identifier conflicts. While IBM initially managed this coordination, a definitive, authoritative list of partition identifiers has been lacking.

Undocumented Practices and Hidden Sectors: The practice of using partitioned or “hidden” sectors within MBR to store specific information is undocumented and can cause severe, difficult-to-diagnose system problems. The proliferation of flawed implementations and tools over time has further complicated MBR support.

Where Can I Find the GPT Specification?

The definitive specification for the GUID Partition Table format is detailed in Chapter 16 of the Extensible Firmware Interface (EFI) specification. This document is publicly accessible on the Intel website:

The Unified EFI Specification Defines an Interface Between an Operating System and Platform Firmware

Third-party information disclaimer: Please note that the link above leads to a third-party website. While we provide this link for informational purposes, conduct.edu.vn is not affiliated with Intel and cannot endorse or guarantee the content on external sites.

Is EFI Required for GPT Disks?

No, EFI is not a prerequisite for utilizing GPT disks. GPT disks are self-identifying. All the necessary information to interpret the partitioning scheme of a GPT disk is contained within structures located at specific, defined locations on the physical storage media itself. This self-descriptive nature makes GPT independent of specific firmware interfaces.

What is the Maximum Size of a GPT Disk?

Theoretically, a GPT disk can reach an immense size of up to 2⁶⁴ sectors in length, based on a single logical block. Logical blocks are commonly 512 bytes (one sector) in size.

In practical terms, operating systems like Windows XP (64-bit) supported GPT disks up to approximately 18 Exabytes. Modern systems and file systems support even larger capacities, far exceeding typical storage needs.

How Many Partitions Can a GPT Disk Have?

In theory, GPT allows for an practically unlimited number of partitions. However, as of July 2001, Microsoft’s implementation limited this to 128 partitions. This limitation is due to the amount of space reserved for partition entries in the partition table. For most users, 128 partitions are more than sufficient.

Can a Disk Be Both GPT and MBR?

No, a disk cannot simultaneously be both a GPT disk and an MBR disk. However, GPT disks incorporate a protective MBR. This protective MBR is designed for compatibility with legacy programs that are not designed to recognize or understand the GPT disk structure.

What is a Protective MBR?

The Protective MBR is located at the very beginning of a GPT disk, in sector 0, preceding the GPT partition table. It contains a single partition of type 0xEE that spans the entire disk. This is consistent regardless of the actual number of partitions defined in the GPT partition entry array.

Why Does GPT Include a Protective MBR?

The Protective MBR’s primary purpose is to safeguard GPT disks from older MBR-based disk tools, such as MS-DOS FDISK or Windows NT Disk Administrator. These legacy tools are unaware of GPT and cannot properly handle GPT disks. When these tools access a GPT disk, they only recognize the Protective MBR. Instead of mistakenly interpreting the GPT disk as unpartitioned or attempting to apply MBR partitioning, these tools view it as having a single, encompassing (and possibly unrecognized) partition, thus preventing accidental data corruption or misinterpretation.

Why Might a GPT Disk Appear to Have an MBR?

If a GPT-partitioned disk appears to have an MBR structure, it strongly suggests that an MBR-only disk tool was used to access the disk. This would lead the tool to only recognize the Protective MBR, masking the underlying GPT structure.

If a Disk Exceeds MBR Size Limits, Is the Entire Disk Protected by the Protective MBR?

Yes. The 0xEE partition within the Protective MBR is intentionally defined to have the maximum size allowable within the MBR scheme. This ensures that legacy MBR tools recognize the entire GPT disk as “used” by a single partition, preventing them from attempting to write MBR-style partitioning information to the disk and potentially corrupting the GPT structure.

Can Windows Read, Write, and Boot from GPT Disks?

Windows support for GPT disks varies depending on the Windows version and architecture:

64-bit Windows XP: Can read and write GPT disks but cannot boot from them. Can read, write, and boot from MBR disks.
32-bit Windows XP: Cannot read or write GPT disks. Only sees the Protective MBR. The 0xEE partition is not mounted or accessible to software. Can read, write, and boot from MBR disks.
Windows 2000, Windows NT 4.0, Windows 98/95: Legacy software. Only sees the Protective MBR on GPT disks. No GPT support.

Modern 64-bit versions of Windows (Windows Vista and later, including Windows 10 and 11) fully support booting from GPT disks and are recommended for systems with UEFI firmware.

Can GPT and MBR Disks Be Mixed on the Same Computer?

Mixing GPT and MBR disks is possible on 64-bit Windows systems, but with certain restrictions:

The Windows boot loader and the boot partition must reside on a GPT disk when booting in UEFI mode. Other data disks can be either MBR or GPT.
Both MBR and GPT disks can coexist within a single dynamic disk group.
Volume sets can span both MBR and GPT disks. However, the MBR cylinder alignment limitations might introduce challenges when mirroring or striping volumes across MBR and GPT disks.

What About Removable Media?

Removable media is generally expected to be either MBR-partitioned or treated as “superfloppy.” GPT is typically not used for removable media due to compatibility considerations with legacy systems.

What is a Superfloppy?

Removable media that lacks both GPT and MBR formatting is considered a superfloppy. In this case, the entire media is treated as a single, unpartitioned storage space.

Media manufacturers usually handle MBR partitioning of removable media. Windows itself does not partition removable media. If removable media has an MBR, only a single partition is supported. In practical use, the distinction between MBR-partitioned removable media with a single partition and superfloppies is minimal for most users.

Examples of removable media include floppy disks, JAZZ disk cartridges, magneto-optical media, DVD-ROM, and CD-ROM. External hard drives connected via interfaces like SCSI or IEEE 1394 are not considered removable media in this context.

What is Windows’ Default Partitioning Behavior?

Windows’ default partitioning behavior varies between 64-bit and 32-bit versions of Windows XP:

64-bit Windows XP: Defaults to GPT partitioning for fixed disks. GPT disks can only be converted to MBR disks after deleting all existing partitions and data.
32-bit Windows XP: Can only use MBR disks. MBR disks cannot be converted to GPT disks in 32-bit Windows XP.

Modern 64-bit versions of Windows, when installed on UEFI-based systems, typically default to GPT partitioning.

Extensible Firmware Interface (EFI) Firmware and Partitions

Mapping Drive Letters to Partitions in EFI Firmware: There is no inherent, direct mapping between operating system drive letters and partitions within the EFI firmware. Basic data partitions are identified by their partition GUIDs for system operations.

Creating an EFI System Partition (ESP): EFI System Partitions can be created using the EFI firmware utility Diskpart.efi, the Windows command-line utility Diskpart.exe, or programmatically using the IOCTL_SET_DRIVE_LAYOUT control code.

Partition Modification Restrictions

Directly modifying partition header entries is strongly discouraged. Users should avoid using disk tools or utilities to make manual alterations or changes to partition structures unless they are fully aware of the risks and implications. Incorrect modifications can lead to data loss or system instability.

Partitioning Support for Detachable Disks in Windows XP

Windows XP supports only MBR partitioning on detachable disks. Detachable disks, such as IEEE 1394 (FireWire) disks or shared disks in Microsoft Cluster Services (MSCS) environments, are expected to be moved between computers or become temporarily unavailable. MBR partitioning ensures compatibility and manageability in these scenarios.

Extensible Firmware Interface (EFI) System Partition in Detail

What is the EFI System Partition (ESP)? The EFI System Partition is a crucial partition containing essential files for booting the computer, including the NTLDR (for older Windows versions), Boot.ini (boot configuration), boot loaders, and device drivers needed during the boot process. The ESP is uniquely identified by the partition GUID: DEFINE_GUID (PARTITION_SYSTEM_GUID, 0xC12A7328L, 0xF81F, 0x11D2, 0xBA, 0x4B, 0x00, 0xA0, 0xC9, 0x3E, 0xC9, 0x3B).

Do Only GPT Disks Have ESPs? No. MBR disks can also have EFI System Partitions. The EFI specification allows booting from both GPT and MBR disks. On MBR disks, an ESP is identified by the partition type 0xEF. However, it’s important to note that Windows XP does not support EFI booting from MBR disks or 0xEF partitions. EFI booting from MBR is more commonly supported in other operating systems or later Windows versions.

Size of the EFI System Partition: The size of the ESP is determined by an algorithm: Max (100MB, min (1 percent of physical disk, 1GB)). In simpler terms, the ESP size is the larger of 100MB or 1% of the physical disk size, capped at 1GB. The disk size is evaluated at the time of partitioning. The 1% calculation is fixed at creation and doesn’t change if the disk is later expanded (e.g., via RAID).

Multiple ESPs on a Single Disk? Creating multiple ESPs on a single disk is not supported and should be avoided. Such a configuration is not architecturally sound and can lead to boot issues.

Multiple ESPs on Different Disks? Replicating ESPs across multiple disks is possible for high-availability setups. However, replication and content synchronization must be performed manually. ESPs cannot be mirrored using standard disk mirroring techniques.

Content of the ESP (Microsoft): Microsoft places the operating system loader and other boot-critical files within the ESP.

Placement of the ESP on Disk: The ESP should ideally be the first partition on the disk. While not a strict architectural requirement, placing it first offers practical advantages. Primarily, it prevents issues with volume spanning. If the ESP is located between two data partitions, it becomes impossible to span those data partitions into a single larger volume.

Content for Computer/Device Manufacturers in the ESP: Manufacturers should limit the ESP to files strictly necessary for booting the operating system, pre-boot platform tools, or files needed for pre-boot system maintenance. Value-added files or diagnostics used after the OS has booted should not reside in the ESP. The ESP is a limited system resource primarily intended for boot-related files.

OEM-Specific Partitions and Value-Added Files

Where to Place OEM Diagnostics and Value-Added Files: The recommended approach for computer manufacturers is to use an OEM-specific partition for value-added content. Similar to MBR OEM partitions, GPT OEM partitions (or other unrecognized partition types) are not exposed as drive letters in Windows and are not visible in volume lists. Users are warned that deleting these partitions may cause system malfunctions. An OEM-specific partition should be placed after the ESP (if present) and before the Microsoft Reserved Partition on the disk. This placement, while not architecturally enforced, mirrors the benefits of placing the ESP first, particularly in preventing volume spanning issues.

While placing pre-boot programs in the ESP is an option, it should be considered carefully. The ESP is shared space and a limited resource. Files not directly related to the pre-boot environment should not be placed in the ESP.

Microsoft Reserved Partition (MRP) Explained

What is the Microsoft Reserved Partition (MRP)? The Microsoft Reserved Partition (MRP) is a reserved space on every GPT disk drive intended for future use by the operating system software. GPT disks do not support hidden sectors, so the MRP fulfills the role that hidden sectors previously played in MBR. Software components that formerly relied on hidden sectors now allocate portions of the MRP for component-specific partitions. For example, converting a basic disk to a dynamic disk will reduce the size of the MRP as a new partition is created within it to hold the dynamic disk database. The MRP is identified by the partition GUID: DEFINE_GUID (PARTITION_MSFT_RESERVED_GUID, 0xE3C9E316L, 0x0B5C, 0x4DB8, 0x81, 0x7D, 0xF9, 0x2D, 0xF0, 0x02, 0x15, 0xAE).

Disks Requiring an MRP: Every GPT disk must have a Microsoft Reserved Partition. The MRP must be the first partition after the EFI System Partition (if one exists) on the disk. It’s crucial that the MRP is created before any primary data partitions.

Who Creates the MRP? The MRP is created when disk partitioning information is initially written to the drive. If a manufacturer partitions the disk, they are responsible for creating the MRP. If Windows partitions the disk during the setup process, it creates the MRP.

Why Create the MRP During Initial Partitioning? Once a disk is fully partitioned with data partitions, there will be no free space left to create the MRP. Therefore, it must be established during the initial partitioning process.

Size of the MRP: The initial size of the MRP depends on the disk drive size:

For drives smaller than 16GB, the MRP is 32MB.
For drives 16GB or larger, the MRP is 128MB.

As the MRP is subdivided to create other partitions (e.g., for dynamic disks), its size will decrease.

Required Partitions for Windows XP

For Windows XP, the following partitions are essential:

Bootable Drive: Must contain an EFI System Partition (ESP), a Microsoft Reserved Partition (MRP), and at least one basic data partition holding the operating system.
Data Drive: Must contain at least a Microsoft Reserved Partition (MRP) and one basic data partition for data storage.

All basic data partitions on a drive should be contiguous. Placing OEM-specific or other unrecognized partitions between data partitions can limit future volume spanning capabilities.

Basic Data Partitions

What is a Basic Data Partition? Basic data partitions in GPT correspond to primary MBR partitions of types 0x6 (FAT), 0x7 (NTFS), or 0xB (FAT32). There is a direct one-to-one mapping between a basic data partition and a drive letter or mount point in the operating system. Each basic data partition is represented as a volume device object in Windows and can optionally be assigned a mount point or drive letter.

Identifying a Basic Data Partition: Basic data partitions are identified by the partition type GUID: DEFINE_GUID (PARTITION_BASIC_DATA_GUID, 0xEBD0A0A2L, 0xB9E5, 0x4433, 0x87, 0xC0, 0x68, 0xB6, 0xB7, 0x26, 0x99, 0xC7).

Visibility of System and OEM Partitions to End Users

Will Users See ESP, MRP, and OEM Partitions? By default, Windows Explorer does not display the EFI System Partition (ESP), Microsoft Reserved Partition (MRP), or OEM-specific partitions. These partitions are not assigned drive letters and their file systems are not exposed to legacy programs like Context Indexing. The ESP, OEM-specific partitions, and other unrecognized partitions are only visible in disk management tools like the Disk Management MMC snap-in.

Default Partition Mounting in Windows

Partitions Mounted by Default: Windows XP primarily exposes basic data partitions. While other partitions with FAT file systems might be mounted internally, they are not exposed with drive letters or mount points by default (only accessible programmatically). Only basic data partitions are assigned drive letters or mount points in typical user scenarios.

The EFI System Partition’s FAT file system is mounted internally but not exposed to the user. This allows Windows programs to update the contents of the ESP when necessary. The registry key HKEY_LOCAL_MACHINE/System/Setup/SystemPartition points to the ESP.

The Microsoft Reserved Partition (and any partitions created within it) may contain recognizable file systems, but none are exposed by default.

OEM-specific partitions or partitions associated with other operating systems are not recognized by Windows. Unrecognized partitions with recognizable file systems are treated similarly to the ESP: they may be mounted internally but not exposed to the user. Unlike MBR disks, there is no practical distinction between OEM-specific partitions and partitions from other OSes in GPT; all are considered unrecognized by default in terms of user visibility.

User Access to System and OEM Partitions

How Users Can See ESP, OEM, and Unrecognized Partitions: Users can utilize disk management tools like the Disk Management MMC snap-in (diskmgmt.msc) or the command-line utility Diskpart.exe to view the EFI System Partition, OEM-specific partitions, and other unrecognized partitions. The Microsoft Reserved Partition and any partitions created from it are typically only visible from a command prompt using disk management utilities.

Dynamic Disks and GPT

Dynamic Disks and GPT Partitions: Dynamic disks, a feature for advanced disk management in Windows, utilize two specific GPT partition types:

Data Container Partition: Corresponds to MBR partition 0x42. GUID: DEFINE_GUID (PARTITION_LDM_DATA_GUID, 0xAF9B60A0L, 0x1431, 0x4F62, 0xBC, 0x68, 0x33, 0x11, 0x71, 0x4A, 0x69, 0xAD). Volumes are created within this container and are mounted by default, similar to the contents of MBR 0x42 partitions.
Dynamic Configuration Database Partition: Holds the dynamic disk configuration database. GUID: DEFINE_GUID(PARTITION_LDM_METADATA_GUID, 0x5808C8AAL, 0x7E8F, 0x42E0, 0x85, 0xD2, 0xE1, 0xE9, 0x04, 0x34, 0xCF, 0xB3).

Basic Disk Conversion to Dynamic Disk

Conversion Process: For a basic disk to be eligible for conversion to dynamic, all basic data partitions on the disk must be contiguous. If any unrecognized partitions are located between basic data partitions, the conversion will fail. This contiguity requirement is a key reason why the Microsoft Reserved Partition must be created before any basic data partitions.

The conversion process involves:

Separating a portion of the Microsoft Reserved Partition to create the configuration database partition for dynamic disk management.
Combining all non-bootable basic partitions into a single data container partition.
Boot partitions are retained as separate data container partitions. This is analogous to the conversion of primary partitions in MBR.

Windows XP’s dynamic disk conversion differs from Windows 2000. In XP, basic and extended partitions are preferentially converted into a single 0x42 partition, whereas Windows 2000 might retain them as multiple distinct 0x42 partitions.

Mounting Specific GPT Partitions

Accessing Different GPT Partition Types: You can access different types of GPT partitions using specific tools:

Diskpart.efi (EFI Firmware): Accesses EFI System Partition and Microsoft Reserved Partition within the EFI firmware environment.
Diskpart.exe (Windows XP): Accesses EFI System Partition and Microsoft Reserved Partition from within Windows XP.
Diskgmt.msc (Windows XP Disk Management): Provides access to EFI System Partition and basic DATA partitions.
Explorer.exe (Windows XP File Explorer): Primarily accesses basic DATA partitions with drive letters.

Developers can also create custom tools using Microsoft Win32 or Win64 APIs for low-level access to GPT disk partitions.

GPT Disk Management in Windows XP

Management Tools and Consistency: GPT and MBR disks are managed in Windows XP using the same tools and interfaces. Disks can be formatted as either GPT or MBR using the Diskpart.exe command-line utility or the Disk Management snap-in. Volumes can be created on both GPT and MBR disks, and both disk types can be mixed within the same dynamic disk group.

FTdisk Sets (Fault Tolerance Disk Sets)

FTdisk Set Support: Windows XP does not support FTdisk sets (fault-tolerant disk sets) for either MBR or GPT disks. Dynamic disks are the sole mechanism for logical volume management and fault tolerance in Windows XP and later versions.

Converting Between GPT and MBR

GPT to MBR or MBR to GPT Conversion: Yes, conversion is possible, but only if the disk contains no partitions or volumes. All data on the disk will be erased during the conversion process. It’s crucial to remember that GPT disks are only supported on 64-bit versions of Windows XP.

File System Support on GPT Disks

Supported File Systems: NTFS is the recommended file system for all basic data partitions and dynamic volumes on GPT disks. Windows Setup and the Disk Management snap-in primarily offer NTFS formatting for GPT disks. However, FAT16 and FAT32 file systems can also be used on GPT partitions. To format GPT partitions with FAT file systems, you must explicitly use the Format tool from the command line, as the GUI tools may default to NTFS for GPT disks.

Sector-by-Sector Copying of GPT Disks

Sector-by-Sector Copies Not Recommended: Performing a sector-by-sector copy of an entire GPT disk is strongly discouraged. The Disk GUID and Partition GUIDs are designed to be unique. Duplicating them through a sector-by-sector copy will result in GUID conflicts, which can cause unpredictable system behavior and management issues. It is acceptable to perform sector-by-sector copies of the contents of individual partitions (like the ESP or basic data partitions), but not the entire disk structure including the GPT tables.

OPK Imaging Tools and GPT Disk Copying

OPK Support for GPT Disk Imaging: Yes, the OEM Preinstallation Kit (OPK) can be used to create images of GPT disks. However, there are important considerations:

GUID Initialization: The OPK initializes Disk and Partition GUIDs to zero in the image.
GUID Generation on First Boot: When Windows XP boots for the first time from an OPK-imaged GPT disk, the operating system automatically generates unique GUIDs for the disk and partitions, replacing the zeroed values.
OPK Partition Support: The OPK primarily supports the creation of EFI System Partitions, Microsoft Reserved Partitions, and basic data partitions.
GUID Dependency Caveats: If any programs, drivers, utilities, or firmware components rely on specific Disk or Partition GUIDs (e.g., for licensing or hardware identification), they must be designed to handle GUIDs that change from the OPK’s initial zero values to the OS-generated unique values. Software should not assume GUIDs remain static after OS installation from an OPK image.

Diskpart.efi MAKE Command

Purpose of Diskpart.efi MAKE Command: The Diskpart.efi MAKE command is designed for OEMs to simplify operating system pre-installation and system recovery processes. It allows for easy creation of a default disk configuration for a given platform. Computer manufacturers can extend the MAKE command to automate partitioning the boot drive with a predefined layout, such as including an ESP, MRP, OEM-specific partition, and a basic data partition.

For example, a manufacturer might define a disk configuration named BOOT_DISK. In a disaster recovery scenario, a command like MAKE BOOT_DISK could completely repartition a boot disk to the original factory default layout.

Handling Duplicate Disk or Partition GUIDs

Duplicate GUID Detection and Resolution: Windows XP is designed to detect duplicate Disk GUIDs, Microsoft Reserved Partition GUIDs, or basic data GUIDs. Upon detection, Windows will automatically generate new, unique GUIDs to resolve the conflicts. This behavior is analogous to how Windows 2000 handled duplicate MBR disk signatures. However, duplicate GUIDs on dynamic container or database partitions can lead to unpredictable and potentially serious system issues. It is critical to ensure GUID uniqueness, especially in dynamic disk environments.

Maximum NTFS Volume Size on GPT Disks

NTFS Volume Size Limits: The maximum NTFS volume size on a GPT disk is primarily determined by the cluster size selected during formatting. NTFS is inherently limited to 2³²-1 allocation units (clusters).

The following table shows NTFS volume size limits based on cluster size:

Cluster size	Maximum NTFS Volume Size (bytes RAW)
512	2,199,023,255,040 (2TB)
1,024	4,398,046,510,080 (4TB)
2,048	8,796,093,020,160 (8TB)
4,096	17,592,186,040,320 (16TB)
8,192	35,184,372,080,640 (32TB)
16,384	70,368,744,161,280 (64TB)
32,768	140,737,488,322,560 (128TB)
65,536	281,474,976,645,120 (256TB)

For example, to format a volume with an 8KB cluster size, use the command: format d: /fs:ntfs /a:8192. If the chosen cluster size is too small for the partition size, you’ll receive an error message: “The format operation did not complete because the cluster count is higher than expected.”

To check the cluster size of a volume, use the command fsutil fsinfo ntfsinfo <driveletter>:. The output will include the “Bytes Per Cluster” value.

fsutil fsinfo ntfsinfo c:

This comprehensive guide should provide a solid understanding of GUID Partition Table (GPT) disks, their advantages over MBR, and their behavior within Windows environments.