GPT Disks

The abbreviation of “GPT” stands for “GUID Partition Table”. Let's look at each of those words, in reverse order:

Globally Unique(-ish) Identifier (“GUID”)

The term “GUID” officially stands for “Globally Unique Identifier”.

The author of this text prefers the term “Globally Unique-ish Identifier”. That is simply to stress the fact that GUIDs are not centralized, and so there is no guarantee that nobody else has decided to use a specific GUID.

With that limit acknowledged, it is worthwhile to understand that the chances of two independently-created GUIDs accidentally matching, if the GUIDs were created with a process that successfully randomizes the numbers, is quite unlikely. That is because there are a large number of possible values to a GUID.

A bunch of possible GUIDs

If you wanted to, you could use an analogy comparing the possible values of a GUID to the number of stars in the known universe. In fact, multiple people have already drawn that analogy. And, comically, they have come up with different answers when doing so.

So apparently the experts agree that there are many GUIDs available per star in the universe, and the number of available GUIDs per star is a number that exceeds twelve digits in length, but there isn't an agreement as to just precisely how big that number actually is.

Are collisions possible?

Like many standards, successfully achieving the goals can depend on proper implementations.

In practice, in Tim's answer to David Basarab's StackOverflow.com question, “Is a GUID unique 100% of the time” he stated, “I have two different web servers using two different sql servers. I went to merge the data and found I had 15 million guids and 7 duplicates.”

StackOverflow.com question comment says, "since the original implementation, where the network card unique serial/id/MAC was used to produce a portion of the key is no longer used, for various reasons, a GUID is not really globally unique any more. It is, however, locally unique."

Multiple standards of GUIDs

Under Adam Davis's answer to David Basarab's StackOverflow.com question, “Is a GUID unique 100% of the time”, the answer's author (Adam Davis) provided a comment which noted, “A GUID is microsoft's specifica implementation of the UUID standard. So, it's both. Globally unique ID vs Universally unique ID.”

Some bits (perhaps those from bits 60 through 63 or 64, or starting at bit 129?) represent a version number, as there are different versions of GUIDs. Details are described further on Wikipedia's article for UUID: section titled “Versions” and IETF RFC 4122 (UUID) section “4.1.3.  Version”.

Since GPT is defined by the UEFI specification, that specification can be used. UEFI Specification Version 2.7 (Errata A), Appendix A, starting on page 2215 (PDF file page 2283) starts out saying, “All EFI GUIDs (Globally Unique Identifiers) have the format described in RFC 4122 and comply with the referenced algorithms for generating GUIDs. It should also be noted that TimeLow, TimeMid, TimeHighAndVersion fields in the EFI are encoded as little endian.” (The Appendix A goes on to provide more details.) For convenience: a hyperlink to IETF RFC 4122: “A Universally Unique IDentifier (UUID) URN Namespace”.)

Some GPT identifiers

The GPT structure uses multiple GUIDs. Each disk gets a GUID as an identifier. Partitions have multiple GUIDs. One of those GUIDs is called the “Partition content type”, which serves the same purpose as the “type ID” byte in the MBR partitioning scheme. The other GUID is meant to simply be an identifier for the partition. In addition to that GUID, the partition also contains bytes 72 bytes intended to store a human-readable name that can be used to help identify the partition.

Citation: Microsoft Windows and GPT FAQ, section called “Why do we need GPT?” states, “Each GPT partition has a unique identification GUID and a partition content type, so no coordination is necessary to prevent partition identifier collision. Each GPT partition has a 36-character Unicode name. This means that any software can present a human-readable name for the partition without any additional understanding of the partition.” (Unicode uses 16-bit characters.)

Although a GUID has enough bits for there to be a very large number of content types, and so there are enough bits that we could easily have a unique “content type” for every different type of popular filesystem, in reality there seems to be fewer “content types” than that. For instance, Wikipedia's article for “GUID Partition Table”, section titled “Partition type GUIDs” shows that in Microsoft Windows, there is a “content type” value of “EBD0A0A2-B9E5-4433-87C0-68B6B72699C7” for a “Basic data partition”. This same data type used regardless of whether a partition is using NTFS or a different filesystem type such as FAT32. Even Linux-based systems have historically used that same partition type, although now Linux-based systems do have their own partition type GUID of 0FC63DAF-8483-4772-8E79-3D69D8477DE4 for basic filesystem data.

Furthermore, the same filesystem type may be used with multiple GPT partition types. For instance, a common type of partition is the Extensible Firmware Interface Service Partition (“EFI Service Partition”, or “ESP”) which uses GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B. The GPT standard indicates that this is using FAT32, which is a filesystem type that might also be used for a “Basic data partition”.

So while the MBR's “partition type ID” byte was often a good indicator of the filesystem type, that is not the case with GPT. GPT's partition type is simply meant to be one way that some software can identify the intended purpose of a partition.

Based on Wikipedia's article for “GUID Partition Table”, section titled “Partition type GUIDs”, it seems that different operating systems have their own standards for some partition types.

For instance, the page shows that:

...can all be mounted separately on partitions that have their own unique known (published) standardized GUID. Furthermore, there are GUIDs for other specific cases, such as:

Yet each of those are listed in the “Linux” section of the table (from Wikipedia's article for “GUID Partition Table”, section titled “Partition type GUIDs”). At the time of this writing, FreeBSD and NetBSD only show six partition GUID types, and OpenBSD shows only one.

So, there are some partition types that are common to many systems, especially 0 (indicating an unused entry), and the Extensible Firmware Interface Service Partition (“EFI Service Partition”, or “ESP”) which are not meant to be highly specific to individual operating systems, many other GPT GUIDs are meant to be used by specific software. As noted already, many operating systems have their own reserved GUIDs, but partitions could be used for other purposes such as GRUB (a popular boot laoder) which may use a partition that it calls the “BIOS boot partition” (using GUID 21686148-6449-6E6F-744E-656564454649).

GDisk may use its own type codes. (GDisk is a shortened name for a program that is offically named “GPT fdisk”.) Rod Smith's answer to a question to john smith's AskUbuntu.com question called “GDisk Hex Codes” notes, “Internally, GPT fdisk translates these codes to GUIDs.” That question on AskUbuntu.com quotes some output from gdisk shows. Perhaps other codes can be seen by GDisk Source Code file parttypes.cc (partition types).

Other GPT details

Wikipedia file: GNU GRUB on GPT partitioned hard disk drives.svg shows some details, such as where the size of a partition entry is specified (and noting that the value is usually 128), the way that bytes are used in a typical 128-bit entry, and that a common layout is to have sectors 2 and 33 (actually, presumably sectors 2 through 33) contain partition entries. That ends up being 32 sectors which, at a half-kilobyte per sector, would end up being enough space for 128 partition entries which are each 128 bytes large.

As just noted, support for 128 partitions is simply “a common layout”. Microsoft Support: “Frequently asked questions about the GUID Partitioning Table disk architecture” provided this information in Q&A format: “How many partitions can a GUID Partition Table disk have?” “In theory, an unlimited number. As the July 2001, the Microsoft implementation is 128 partitions. The number of partitions is limited by the amount of space that is reserved for making partition entries.”

Using LBA64 (that is, LBA and 64-bit values), the largest partition size would be 2^64 which would be 18,446,744,073,709,551,616 logical blocks. (Although, if that wasn't enough, it looks like the GPT format could allow specifying a larger amount, by increasing the specified size of the partition entry size.)

Currently, it seems that some operating system limitations are likely to affect people before the limitations imposed by the format of the GPT layout. For instance, while GPT supports 18,446 quadrillion logical blocks, Windows Server 2003 SP1 and newer versions of Microsoft Windows are limited to 18,446 quadrillion octets.

Some big numbers
  • (This was only vaguely cleaned up from scratch notes, and might not be aligned in quite the most sensible manner, particularly when comparing to original quoted text... Also, some new text may have been merged in with some quoted/cited text, so that should be cleaned up some day...)
  • Some current size limits:
    • In theory, a GPT disk can be up to 2^64 logical blocks in length. Logical blocks are commonly 512 bytes in size.
    • The maximum partition (and disk) size is a function of the operating system version. Windows XP and the original release of Windows Server 2003 have a limit of 2TB per physical disk, including all partitions. For Windows Server 2003 SP1 Windows XP x64 edition, and later versions, the maximum raw partition of 18 exabytes can be supported. (Windows file systems currently are limited to 256 terabytes each.) https://web.archive.org/web/20090309050151/http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx
    • 2^64= 18,446,744,073,709,551,616
      • Exactly 16 “binary exabytes&dquo; (“ebibytes”?)... that is, 16 * 1,152,921,504,606,846,976
      • Approximately 18 exabytes + 446 Petabytes + 744 Terabytes + 73 gigabytes + 709 megabytes + 551 kilobytes, plus precisely 616 bytes
      • “Approximately” is said because what we're really looking at involves:
        • 2^ 10 = 1KB = 1024 bytes
        • 2^ 20 = 1 MB = 1,048,576 (1,024 KB)
        • 2^ 30 = 1 GB = 1,073,741,824 (1,024 MB)
        • 2^ 40 = 1 TB = 1,099,511,627,776 (1,024 GB)
        • 2^ 50 = 1 PB = 1,125,899,906,842,624 (1,024 TB)
        • 2^ 60 = 1 EB = 1,152,921,504,606,846,976 (1,024 PB)
        • 2^ 64 = 16 EB = 18,446,744,073,709,551,616 bytes
      • “(Windows file systems currently are limited to 256 terabytes each.)” (So, a quarter-petabyte.)
    • https://web.archive.org/web/20090309050151/http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx from May 3, 2006 (Reviewed July 8, 2008) (seeming to discuss Windows Server 2003 as if that was most recent)
      • 2^50 = 1 Petabyte = 1,125,899,906,842,624
      • 2^60 = 1 Exabyte = 1,152,921,504,606,846,976
      • 2^61 = 2,305,843,009,213,693,952
      • 2^62 = 4,611,686,018,427,387,904
      • 2^63 = 9,223,372,036,854,775,808
      • It seems Windows Calc only wants to count up to 9,223,372,036,854,775,807 nicely... 2^64 = 18,446,744,073,709,551,616
      • https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions "Each partition can have a maximum of 18 exabytes (~18.8 million terabytes) of space."
      • 2^70 = Zettabyte
      • 2^80 = Yottabyte
      • As of 2015, there are no approved standard sizes for anything bigger than a Yottabyte. However, the two standards that have been proposed are the Hellabyte or Brontobyte. https://www.computerhope.com/issues/chspace.htm
      • 2^122 (e.g., number of random bits in UUID) - easiest way to calculate that manually might be dividing by 2 six times, from
      • 2^128 = # of IPv6 addresses = 340,282,366,920,938,463,463,374,607,431,768,211,456

GPT Standard

Microsoft Support: Frequently asked questions about the GUID Partitioning Table disk architecture has a question, “Where can I find the specification for GUID Partition Table disk partitioning?” The page refers people to a chapter in the Extensible Firmware Interface specification.

UEFI Specifications provides specifications. (Note: In the “Latest Versions of the UEFI Specifications” section, the first sub-section is “ACPI Specification”. If that is not what you are looking for, make sure to get a file from the second sub-section called “UEFI Specification”. For details about UEFI, you could also look over System Startup: Firmware using the [U]EFI Standard.)

e.g., UEFI Specification Version 2.7 (Errata A), page 115 (PDF file page 183)

Some common GPT Types

Section Summary

This list covers some neutral types, and is perhpas a bit heavy in favor of covering typical partition types likely to be found on many systems running Microsoft Windows. This does not currently go into many of the other partition types, such as Storage Spaces (even if they are commonly seen on Microsoft Windows).

Requirements vs. recommendations
Evidence

A person could have justified cause to start to think that there are rigid requirements to the order of partitions. For instance, Windows Server documentation: creating an MSR partition provides a note that says, “Caution”... since “gpt disks require a specific partition layout, creating Microsoft Reserved partitions could cause the disk to become unreadable.”

However, there can be some flexibility. Microsoft Support: “Frequently asked questions about the GUID Partitioning Table disk architecture” says, “The Extensible Firmware Interface System Partition must be first on the disk. While there is no architectural requirement, there are numerous reasons why it is beneficial to place the Extensible Firmware Interface System Partition first. The primary reason for this” is to allow flexibility with disk spanning.” (Hyperlinks added to qutoed text.)

So, that's not really a technical requirement for the GPT disk architecture. It's really a recommendation.

Microsoft Windows and GPT FAQ says, “An OEM-specific partition should be placed before the MSR and after any ESP on the disk. Although not architectural, this placement has the same benefits as placing the ESP first. For example, it is also impossible to span volumes when an OEM-specific partition is logically between the two data partitions that you are attempting to span.”

Furthermore, Microsoft notes the requirement of an MSR partition on every GPT disk. However, people have reported success in installing Microsoft Windows onto disks with a single partition, and no ESP or MSR partition.

Yet, despite that apparently not being a requirement, Microsoft Support: “Frequently asked questions about the GUID Partitioning Table disk architecture” notes, “Every GUID Partition Table disk must contain an Microsoft Reserved Partition. The Microsoft Reserved Partition must be the first partition after the Extensible Firmware Interface System Partition (if any) on the disk. It is particularly important that the Microsoft Reserved Partition be created before other primary data partitions.”

So although Microsoft provides some quotes of “requirements” that “must” happen, many of them are not actually enforced technical requirements. Still, Microsoft is quite intentional about making the point that having an MSR come before the data partition is “particularly important”.

Another example is the “Microsoft Windows Recovery Environment tools” partition. Documentation about this partition mentions a technical advantage of placing it right after the boot partition. Namely, some partition resizing can occur. (The documentation seems to make it sound like this may be automatic.) Yet the documentation does also mention a (possible) procedure of moving the “Microsoft Windows Recovery Environment tools” partition after data partitions. So it seems like that partition certainly can exist in different spots, although the location of being right after the boot drive may truly be better than the other location of being after any other data partitions.

Conclusion

Microsoft has specified a lot of “requirements”, or things that “must” be true, when those details are not actual requirements. However, Microsoft does provide the recommendations, and it looks like there are some actual advantages in at least some cases.

[#gptefisp]:

Extensible Firmware Interface (“EFI”) System Partition (“ESP”)

GUID Partition Type: C12A7328-F81F-11D2-BA4B-00A0C93EC93B
GDisk Type Code: EF00
Purpose: Data used during early part of a boot process; remainder is generally wasted space
Size: 100 MB - 1 GB
Location: First

The Extensible Firmware Interface (“EFI”) System Partition is abbreviated a ESP.

ESP GUID

The value of C12A7328-F81F-11D2-BA4B-00A0C93EC93B is documented as part of the UEFI specification. e.g., UEFI Specification Version 2.7 (Errata A), page 126 (PDF file page 194), Table 22.

Microsoft “Previous Versions Documentation”, “Windows and GPT FAQ quoted: “DEFINE_GUID (PARTITION_SYSTEM_GUID, 0xC12A7328L, 0xF81F, 0x11D2, 0xBA, 0x4B, 0x00, 0xA0, 0xC9, 0x3E, 0xC9, 0x3B)

ESP Size

Microsoft Documentation: “UEFI/GPT-based hard drive partitions”, section called “Drive Partition Rules” says, “The minimum size of this partition is 100 MB, and must be formatted using the FAT32 file format.”

MS KB 302873: Frequently asked questions about the GUID Partitioning Table disk architecture indicates that for disks that are 10 times the size of 100 MB (so, about 10 GB) up through 100 GB, that the ESP be 1% of the disk space, and for disks that are over 100GB, to just have the ESP be 1 GB.

Likewise, Microsoft Support: “Frequently asked questions about the GUID Partitioning Table disk architecture” also mentions a 100MB minimum, and if enough space permits, using 1% of the physical disk but not exceeding 1GB.

TenForums.com Tutorial: How to Clean Install Windows 10 refers to “the 450 MB (UEFI-GPT) or 500 MB (Legacy BIOS-MBR) System Reserved partition” created by Microsoft Windows Setup (when installing the operating system).

Location

Microsoft Windows and GPT FAQ says: “The ESP should be first on the disk. The primary benefit to placing the ESP first, is that it is impossible to span volumes when the ESP is logically between the two data partitions that you are attempting to span.”

Microsoft Support: “Frequently asked questions about the GUID Partitioning Table disk architecture” says, “The Extensible Firmware Interface System Partition must be first on the disk. While there is no architectural requirement, there are numerous reasons why it is beneficial to place the Extensible Firmware Interface System Partition first. The primary reason for this is that it is impossible to span volumes when the Extensible Firmware Interface System Partition is logically between the two data partitions you are attempting to span.”

Naming

When using Microsoft's DiskPart program, the program may identify this as “System”. For instance, when using and using LIST VOLUME, the Info column may show this as “System”. See also: Wikipedia's page on “System partition and boot partition” to see how that terminology differs from what is used by most other software.

Data on an ESP

This contains the boot loader.

For Microsoft Windows systems, Microsoft's Microsoft Windows and GPT FAQ says, “The ESP contains the NTLDR, HAL, Boot.txt, and other files that are needed to boot the system, such as drivers.” Later, that same document notes, “Microsoft places the HAL, loader, and other files that are needed to boot the operating system in the ESP.” Microsoft Windows and GPT FAQ says:

“The ESP should only include files that are required for booting an operating system, platform tools that run before operating system boot, or files that must be accessed before operating system boot. For example, files that are required for performing pre-boot system maintenance must be placed in the ESP.

Other value-add files or diagnostics used while the operating system is running should not be placed in the ESP. It is important to note that the space in the ESP is a limited system resource; its primary purpose is to provide storage for the files that are needed to boot the operating system.”

Microsoft Support: “Frequently asked questions about the GUID Partitioning Table disk architecture” says, “The Extensible Firmware Interface System Partition contains the NTLDR, Boot.ini, and other files that are necessary to boot the computer, such as drivers.”

TenForums.com Tutorial: How to Clean Install Windows 10 states, “System Reserved partition is used for the Boot Manager code, BCD (Boot Configuration Database), System Recovery Options (Windows RE), and start up files for BitLocker (if turned on).”

Using the ESP

Beware! Filling this up might cause some problems that are probably worth avoiding.

Microsoft Windows and GPT FAQ notes that files “used while the operating system is running should not be placed in the ESP. It is important to note that the space in the ESP is a limited system resource; its primary purpose is to provide storage for the files that are needed to boot the operating system.”

Microsoft Support: “Frequently asked questions about the GUID Partitioning Table disk architecture” incorrectly states, “The Extensible Firmware Interface System Partition, OEM-specific, and other unrecognized partitions will be visible only in the Disk Management MMC snap-in.”

However, it can also be used by a couple of other programs.

Microsoft Documentation: “UEFI/GPT-based hard drive partitions”, section called “Sample files: configure drive partitions by using Windows PE and DiskPart scripts” seems to assign S: (presumably as a “drive letter”) for this type of partition.

Or, you can follow this documentation. From a UAC-elevated command prompt, run DiskPart. Identify and select the desired disk, and identify and select the System Partition. e.g.:


Microsoft DiskPart version 10.0.17134.1

Copyright (C) Microsoft Corporation.
On computer: ComputerName

DISKPART> LIST DISK

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          931 GB   373 GB        *

DISKPART> SELECT DISK 0

Disk 0 is now the selected disk.

DISKPART> LIST PARTITION

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    System             260 MB  1024 KB
  Partition 2    Reserved            16 MB   261 MB
(Other partitions...)

DISKPART> SELECT PARTITION 1

Partition 1 is now the selected partition.

DISKPART> DETAIL PARTITION

Partition 1
Type    : c12a7328-f81f-11d2-ba4b-00a0c93ec93b
Hidden  : Yes
Required: No
Attrib  : 0X8000000000000000
Offset in Bytes: 1048576

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
* Volume 5         SYSTEM_DRV   FAT32  Partition    260 MB  Healthy    System

DISKPART> ASSIGN LETTER=S

DiskPart successfully assigned the drive letter or mount point.

DISKPART>

Then you can choose to, once again, perform the optional step of running the “DETAIL PARTITION” command.

DISKPART> DETAIL PARTITION

Partition 1
Type    : c12a7328-f81f-11d2-ba4b-00a0c93ec93b
Hidden  : Yes
Required: No
Attrib  : 0X8000000000000000
Offset in Bytes: 1048576

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
* Volume 5     S   SYSTEM_DRV   FAT32  Partition    260 MB  Healthy    System

DISKPART>

When you're done looking at the information provided by this program:

DISKPART> EXIT

Alternatively, instead of using DiskPart, you could also try “MountVol S: /S”. (Microsoft Support 314943: “Cannot Access an EFI System Partition with the Mountvol Utility in a WinPE Environment” notes that environment not supporting this approach.)

OEM (to be saved)

Location: After the ESP (if an ESP exists on the drive), and before MSR (which comes before boot or other data)
(Identical in placement consideration as other operating systems)

The author of this text recommends that people simply keep any pre-existing OEM partitions on the drive, at least while the computer is in warranty. (If a computer has an issue while it is in warranty, OEM return policies might involve processes that may try to utilize such software.) Once a computer is out of warranty, there may be many cases where a sufficiently knowledgable, careful, and competent person may be best off removing the partition just to get some more disk space.

OEM Location

Microsoft Windows and GPT FAQ says, “An OEM-specific partition should be placed before the MSR and after any ESP on the disk. Although not architectural, this placement has the same benefits as placing the ESP first. For example, it is also impossible to span volumes when an OEM-specific partition is logically between the two data partitions that you are attempting to span.”

Microsoft Documentation: “UEFI/GPT-based hard drive partitions”, section called “Drive Partition Rules” says, “Any other utility partitions not managed by Windows must be located before the Windows, data, and recovery image partitions. This allows end users to perform actions such as resizing the Windows partition without affecting system utilities.”

Non-Microsoft Operating systems

Location: After the ESP (if an ESP exists on the drive), and before MSR (which comes before boot or other data)
(Identical in placement consideration as OEM data)

Microsoft's GPT FAQ does note, “there is no practical difference between OEM-specific partitions and other operating system partitions”.

Microsoft Windows and GPT FAQ says, “An OEM-specific partition should be placed before the MSR and after any ESP on the disk. Although not architectural, this placement has the same benefits as placing the ESP first. For example, it is also impossible to span volumes when an OEM-specific partition is logically between the two data partitions that you are attempting to span.”

Microsoft Documentation: “UEFI/GPT-based hard drive partitions”, section called “Drive Partition Rules” says, “Any other utility partitions not managed by Windows must be located before the Windows, data, and recovery image partitions. This allows end users to perform actions such as resizing the Windows partition without affecting system utilities.”

Unused

GUID Partition Type: 00000000-0000-0000-0000-000000000000
GPT Type Code: ???? (probably zero)

This “GUID Partition Type” identifier is all zeros.

[#gptmsrsr]:

Microsoft Reserved Partition (“MSR”)

GUID Partition Type: E3C9E316-0B5C-4DB8-817D-F92DF00215AE
GPT Type Code: 0C01
Purpose: Generally wasted space
Size: 16MB, historically either 32MB or 128 MB.
Location:
  • On each drive
  • After the ESP (if an ESP exists on the drive), after any OEM partitions (that are not temporary), after any partitions for other operating systems
  • Before the boot partition, and before any other typical data partitions for Microsoft Windows
MSR Partition GUID

Microsoft Windows and GPT FAQ says: “DEFINE_GUID (PARTITION_MSFT_RESERVED_GUID, 0xE3C9E316L, 0x0B5C, 0x4DB8, 0x81, 0x7D, 0xF9, 0x2D, 0xF0, 0x02, 0x15, 0xAE)

MSR Sizes

Microsoft Documentation: “UEFI/GPT-based hard drive partitions” states, “Beginning in Windows 10, the size of the MSR is 16 MB.”

Prior versions of Microsoft Windows had larger sizes. Disks that are at least 16 GB may have an MSR of 128 MB (131,072 KB = 134,217,728 bytes). Disks under 16GB had the Microsoft Windows operating system installation process create an MSR partition which is 32MB (= 32,768 KB = 33,554,432 bytes).

Microsoft Support: “Frequently asked questions about the GUID Partitioning Table disk architecture” notes, “Every GUID Partition Table disk must contain an Microsoft Reserved Partition. The Microsoft Reserved Partition must be the first partition after the Extensible Firmware Interface System Partition (if any) on the disk. It is particularly important that the Microsoft Reserved Partition be created before other primary data partitions.”

However, Microsoft Windows and GPT FAQ says, “An OEM-specific partition should be placed before the MSR and after any ESP on the disk. Although not architectural, this placement has the same benefits as placing the ESP first. For example, it is also impossible to span volumes when an OEM-specific partition is logically between the two data partitions that you are attempting to span.”

Windows Server documentation: creating an MSR partition has a section that says “Caution”: “Be very careful when using this command. Because gpt disks require a specific partition layout, creating Microsoft Reserved partitions could cause the disk to become unreadable.”

MSR Data Usage

Wikipedia's article on “Microsoft Reserved Partition”, “Usage” section states, “For normal operation when the system is booted, the MSR partition is usually no longer needed”... “some security tools may add their own data or software components in the MSR for checking the system integrity at boot time. Some UEFI boot tools may also use the MSR” ... “In summary, the actual usage and content of the MSR is very device-specific and invisible to normal application software or to the Windows API”.

Wikipedia's article on “Microsoft Rserved Partition”, section called “Usage” notes that with “the Windows API”... “the MSR partition is not exposed as a mountable volume (it contains no standard filesystem).” Wikipedia's article on “Microsoft Reserved Partition”, “Usage” section states, “Contents in the MSR generally have some data signature to identify the content and make sure it is meaningful, but this signature is vendor-specific to each hardware component using it.”

Wikipedia's article on “Microsoft Rserved Partition”, section called “Usage” has some ntoes about different partition types. It talks about deleting a partition for the purpose of then “so then the main data partition may be extended over the free space where the old” partition was, and notes that “during this operation, the small MSR partition may be temporarily used as a scratch area for recovery in case of unexpected failure of the conversion such as battery/power failure”. This is rather in line with Microsoft Documentation: “UEFI/GPT-based hard drive partitions”, section called “Drive Partition Rules” nothing, “This allows end users to perform actions such as resizing the Windows partition without affecting system utilities.” So, it sounds like the MSR partition has been used during some partition-resizing tasks, and that perhaps the reason for the MSR being used was to back up some details that could aid recovery in case of an interruption in the partition-resizing tasks.

Microsoft Documentation: “UEFI/GPT-based hard drive partitions”, section called “Drive Partition Rules” states, “The MSR is a reserved partition that does not receive a partition ID.” Except, it does receive a GUID Partition Type of E3C9E316-0B5C-4DB8-817D-F92DF00215AE so that statement is probably just intending to mean that no drive letter is assigned. After all, Wikipedia's article on “Microsoft Rserved Partition”, section called “Usage” notes that with “the Windows API”... “the MSR partition is not exposed as a mountable volume (it contains no standard filesystem).”

Compatibility

According to Ben N's answer to a SuperUser.com question, “How to change GPT partition type on windows?”, DiskPart won't let a user set an existing partition to use the MSR partition type GUID. This is because DiskPart finds the related GUID in a file called “vdsbas.dll (in System32)”. (Presumably a solution would be to just remove the undesired partition, and re-create it. Windows Server documentation: creating an MSR partition notes being able to use the “create partition msr” command.)

[#gptmswbt]:

Microsoft Windows Boot Partition/Volume

GUID Partition Type: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
GPT Type Codes: Mainly:
0700
Also: 0100 0400 0600 0700 0B00 0C00 0E00 1100 1400 1600 1700 1B00 1C00 1E00
Purpose: Store a Microsoft Windows operating system's installation
Size: Big (commonly 20+ GB?)
Location:
  • After MSR (and after ESP, OEM, Non-Microsoft Operating Systems)
  • Before Recovery Environment, and before other Microsoft Basic Data partitions

This partition uses the same partition (GUID) type ID as a “Microsoft Basic Data Partition”. What makes this partition different than other “Microsoft Basic Data Partition” is that the operating system boots from this partition. (There can be multiple such partitions on a disk, if Microsoft Windows operating systems are installed on different partitions, but presumably only one of them will be actively booted at any one moment of time.)

Wikipedia's page on “System partition and boot partition”

Naming

When using Microsoft's DiskPart program, the program may identify this as “Boot”. For instance, when using and using LIST VOLUME, the Info column may show this as “Boot”. See also: Wikipedia's page on “System partition and boot partition” to see how that terminology differs from what is used by most other software.

Size

This should be large enough to store the Microsoft Windows installation, and have enough room to spare so the operating system can be sufficiently patched. The precise size required will depend on which operating system is being used. (You may wish to check User-Targetting Microsoft Windows Platforms and/or “Microsoft OS code, and compatible/similar”, section about operating systems/code marketed as having code meant to run “Microsoft Windows” programs for possible information about disk requirements.

[#gptmswre]:

Recovery Environment (for Microsoft Windows)

GUID Partition Type: DE94BBA4-06D1-4D40-A16A-BFD50179D6AC
GPT Type Code: 2700
Purpose: Contain data for Windows Recovery Environment
Size: At least 320MB, and perhaps 1 GB more than that
Location: After boot partition
(ideally immediately after the boot partition ; ideally before other Microsoft Basic Data partitions)
Name
Microsoft Documentation: “UEFI/GPT-based hard drive partitions”, section called “Drive Partition Rules” refers to this as the “Windows RE partition”. There is also a section named “Recovery tools partition” which is about this type of partition. In that section, it refers to “the Windows Recovery Environment tools image”.
Optional
This partition is mentioned by Microsoft Documentation: “Windows Recovery Environment (Windows RE)”. This is not mentioned in the main body of the Microsoft Windows and GPT FAQ.
Size

Simple answer: Make this 1.3 GB or a bit larger.

Microsoft Documentation: “UEFI/GPT-based hard drive partitions”, section called “Drive Partition Rules” says, “This partition must be at least 300 MB.” However, further reading says, “This partition must have enough space for the Windows Recovery Environment tools image (winre.wim, typically between 250-300MB, depending on base language and customizations added), plus enough free space” to meet other requirements. The documented required amount of free space is either 50MB or 320MB, but if the partition is at least 1GB, Microsoft recommends “that it should have at least 1 GB free.” (In order to have 1GB free, if 300MB is used up, this means that the partition should be about 1.3GB at minimum.)

The winre.win file will need to fit into RAM. So if a system has 16 GB of RAM and if people know that will never increase (probably due to a motherboard's maximum limit of RAM), then having a tremendously larger Windows Recovery Environment partition might just be pretty wasteful.

Location

In Microsoft Documentation: “UEFI/GPT-based hard drive partitions”, section called “Drive Partition Rules”, the sub-section called “Recovery tools partition” says, “We recommend that you place this partition immediately after the Windows partition. This allows Windows to modify and recreate the partition later if future updates require a larger recovery image”

One drawback to this layout is provided later in Microsoft Documentation: “UEFI/GPT-based hard drive partitions”, section called “Drive Partition Rules”, in the “Data partitions” sub-section. Here, the document notes:

“This layout makes it more difficult for end users to remove the data partition and merge the space with the Windows partition. To do so, the Windows RE partition must be moved to the end of the unused space reclaimed from the data partition, so that the Windows partition can be extended.

Windows 10 does not include functionality or utility to facilitate this process.”

Based on that quoted text, it would seem like a better spot for the Windows Recovery Environment, so that there would not be a need to try to manually move it later. However, Microsoft's earlier recommendation is to place this right after the Microsoft Windows boot drive, so that the boot drive can modify this if needed.

Interestingly, it seems that Microsoft doesn't implement its own advice. According to information seen at TenForums.com Tutorial: How to Clean Install Windows 10 (and mixing in some other details), 64-bit Microsoft Windows using UEFI will create four partitions, the first of which is the “Recovery” partition. (At the moment, the author of this text is presuming that is a DE94BBA4-06D1-4D40-A16A-BFD50179D6AC partition.)

Multiple recovery partitions

In actual practice, a Lenovo laptop has been seen coming with two of these partitions. One was about a GB (DiskPart actually reported it as “1000 MB”), and had a label of WINRE_DRV. The other was about 18GB and had a label of LENOVO_PART. Both used the GUID of DE94BBA4-06D1-4D40-A16A-BFD50179D6AC.

Typical data

Microsoft Documentation: “Windows Recovery Environment (Windows RE)” notes, “By default, WinRE is preloaded into the Windows 10 for desktop editions (Home, Pro, Enterprise, and Education) and Windows Server 2016 installations.” Later, that page explains further, “Windows initially places the WinRE image file (winre.wim) in the Windows partition, in the \Windows\System32\Recovery folder.” (Later, while still running Windows Setup) “the WinRE image file is copied into the recovery tools partition, so that the device can boot to the recovery tools even if there's a problem with the Windows partition.”

Using the partition

Microsoft Documentation: “UEFI/GPT-based hard drive partitions”, section called “Sample files: configure drive partitions by using Windows PE and DiskPart scripts” seems to assign R: (presumably as a “drive letter”) for this type of partition.

Basic Data Partitions
[#gptmsbdp]:

Microsoft Basic Data Partition (“MS BDP”)

GUID Partition Type: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
GPT Type Code: 0700
Purpose: Store Additional Data
Size: Big (commonly 20+ GB?)

Microsoft has a “Basic Data” partition type.

Older versions of Linux-based operating systems may have also used this, although newer versions of Linux-based operating systems may be more prone to use 0FC63DAF-8483-4772-8E79-3D69D8477DE4

Newer versions of Microsoft Windows have a command named DISKPART. If, at the “DISKPART>” prompt, the typed command is “HELP CREATE PARTITION PRIMARY”, then some of the output says, “Basic data partition” and then shows the GUID “ebd0a0a2-b9e5-4433-87c0-68b6b72699c7”.

This same GUID is used for a “Microsoft Windows Boot Partition”/Volume (as described in some earlier documentation).

Desired size: According to Microsoft's latest guidelines, non-existent. (Instead, just make the Microsoft Windows Boot Partition/Volume larger, containing the space that this type of partition may use.) However, if the Microsoft Windows Boot Partition/Volume is not made as large as it can be, and this partition exists, then the general idea (from Microsoft's guidelines) is probably to have this partition be as big as needed to completely fill the remaining space.

Note: You do not always need to feel compelled to partition space right away. (The main/top page about Disk Layout section, sub-section called “Partition Size” discusses the idea of having some space left unpartitioned.

[#gptmsldm]:

LDM-related partition on a dynamic disk

Newer versions of Microsoft Windows have a command named DISKPART. If, at the “DISKPART>” prompt, the typed command is “HELP CREATE PARTITION PRIMARY”, then some of the output says, “LDM Metadata partition on a dynamic disk:” and then shows the GUID “5808c8aa-7e8f-42e0-85d2-e1e90434cfb3”. then some of the output says, “LDM Data partition on a dynamic disk:” and then shows the GUID “af9b60a0-1431-4f62-bc68-3311714a69ad”. MicrosoftWin32 API System Services, CREATE_PARTITION_PARAMETERS structure (vds.h) documentation at https://docs.microsoft.com/en-us/windows/win32/api/vds/ns-vds-create_partition_parameters document these values, and note about both, “This value can be set only for dynamic disks.”

Disposable OEM Partitions

Wikipedia's article on “Microsoft Rserved Partition”, section called “Usage” is about one type of partition, but discusses others. It notes, “For PCs preinstalled with a single SSD, the OEM recovery partition is usually at end of disk (this allows this OEM partition to be backed up to an external DVD or USB drive and then deleted from the SSD, for extending the main data partition over it after the OEM backup has been done without having to move all sectors on the SSD”.

This seems to go in contrast to Microsoft's documentation, but Microsoft's documentation provides a reason of wanting to save the partition. For instance, Microsoft Documentation: “UEFI/GPT-based hard drive partitions”, section called “Drive Partition Rules” says, “Any other utility partitions not managed by Windows must be located before the Windows, data, and recovery image partitions. This allows end users to perform actions such as resizing the Windows partition without affecting system utilities.” If the system utilities are unaffected, that would imply that the OEM drive containing those system utilities is preserved.

Another example from some official documentation by Microsoft is that right before noting the recommended location for an OEM drive, Microsoft Windows and GPT FAQ notes, “Users are warned that deleting the partition can cause the system to fail to operate.”

However, the Wikipedia page's note describes an intended purpose of being able to be deleted, so that note from Microsoft's documentation might not apply to this scenario. It seems that Microsoft's documentation might not provide an official recommendation that is being followed in such cases, so the best way to understand the actual conventions typically being used may be to just pay attention to real common practice. In that case, Wikipedia's note may be most relevant.

If an OEM partition is found at the end of the hard drive, first make sure that this is actually unnecessary OEM data, and not actually desirable data which is from another operating system and which simply got lumped into a description of “OEM partition”. If this is actually less necessary data, you may want to consider backing it up onto less valuable media and then deleting the drive. (For instance, a sufficiently-large optical disc (e.g., a DVD-R or BD-R... the hardware section may describe optical discs further) may have a lot lower cost per byte than a recent main storage device that is designed to be re-written more frequently, and accessed faster.)

Misc/Unknown
E3C9E316-0B5C-4DB8-817D-F92DF00215AE ( GDisk Type Code 0x0C01 )

[#gptlnxpt]: Linux-Based Operating Systems (Common Partition Types)

Section Summary

...

Extensible Firmware Interface (“EFI”) System Partition (“ESP”)

GUID Partition Type: C12A7328-F81F-11D2-BA4B-00A0C93EC93B
GPT Type Code: ef00
Purpose: Data used during early part of a boot process; remainder is generally wasted space
Size: 100 MB - 1 GB

The Extensible Firmware Interface (“EFI”) System Partition is abbreviated a ESP.

The size recommendation comes from Microsoft's recommendations. For further details, see the details about the Extensible Firmware Interface (“ESP”) System Partition (“ESP”) which are documented in the Microsoft section.

[#gptbbtpt]:

BIOS Boot Partition

GUID Partition Type: 21686148-6449-6E6F-744E-656564454649
GPT Type Code: EF02
Purpose: GNU Grub V2 support for BIOS
Size: 1MB (1,048,576) bytes, or possibly even smaller (32 KB)

Despite the rather nuetral-sounding name that doesn't mention GRUB at all, it seems like this partition type is specifically used for a single type of setup, which is having GNU GRUB v2 work with a BIOS system that supports GPT. Wikipedia's article on “Unified Extensible Firmware Interface” (“UEFI”), section on Compatibility, sub-section on “Disk device compatibility”, sub-section titled “Linux” notes, “This partition is not required if the system is UEFI-based because no embedding of the second-stage code is needed in that case.”

GRUB BIOS Installation Notes says, “When GRUB finds a BIOS Boot Partition during installation, it will automatically overwrite part of it. Make sure that the partition does not contain any other data.”

Some documentation on GPT (by Roderick W. Smith, maintainer of rEFInd) notes, “The BIOS Boot Partition can be as small as 32KiB in some configurations, although it must sometimes be a bit larger. Given modern partition alignment policies, a size of 1MiB is common.” To be safe, 1 MB is recommended. (On a system that supports GPT, disk sizes exceeding 2 Terabytes are likely, so 1MB will typically be a relatively small amount of space.) Arch Linux documentation for GRUB notes, “GRUB for GPT, however, does not use the Post-GPT gap” (similar to how GRUB uses a Post-MBR gap), and it seems the reason may be “to conform to GPT specifications that require 1_megabyte/2048_sector disk boundaries.”

BBP Partition GUID

The bytes of the GUID Partition Type value for BIOS Boot Partition, 21686148-6449-6E6F-744E-656564454649, were clearly not created randomly, as when they are converetd into ASCII they show up as “!haHdInotNeedEFI”. That is actually intended to be interpreted by using a “Little-Endian” conversion where the first four bytes are viewed in reverse order, and then each of the next two pairs of bytes are viewed in reverse order, resulting in the message of “Hah! I don't Need EFI”.

Microsoft's thoughts

Microsoft's GPT FAQ (e.g., Microsoft Windows Hardware Dev Center: Windows and GPT FAQ Version 1.1 (as archived by the Wayback Machine @ Archive.org from Feburary 19, 2011)) does not provide any specific information about a BBP GUID, which isn't too surprising since GRUB v2 uses the GPL. Most likely, the documentation by Microsoft that is probably meant to apply to the BBP would be comments about OEM partitions. Microsoft's GPT FAQ does note, “there is no practical difference between OEM-specific partitions and other operating system partitions”.

Microsoft Documentation: “UEFI/GPT-based hard drive partitions”, section called “Drive Partition Rules” says, “Any other utility partitions not managed by Windows must be located before the Windows, data, and recovery image partitions.” BBP could arguably be considered to be a “Utility partition”, so treating this like an OEM drive would seem to be most sensible.

[#gptosrtp]:

Linux-based OS Root Partition

GUID Partition Type: Multiple (varies)
GPT Type Code: ????
Purpose: Serve as a top-level directory
Size: Small is often okay

According to FreeDesktop.org's “The Discoverble Partitions Specification”, five different GPT entries can be related to a “Root Partition” can be specified depending on the platform.

DescriptionGUIDGPT
Type
Root (x32 x86) 44479540-f297-41b2-9af7-d131d5f0458a 8303
Root (x64) 4f68bce3-e8cd-4db1-96e7-fbcaf984b709 8305
Root (64-bit ARM/AArch64) b921b045-1df0-41c3-af44-4c6f280d3fae 8305
Root (32-bit ARM) 69dad710-2ce4-4e3c-b16c-21a1d49abed3 8307
Root (“Intel Itanium”/“Intel Architecture 64” (“IA64”)) 993d8d3d-f80e-4225-855a-9daf8ed7ea97

Root Verity

GUID Partition Type: Multiple (varies)
GPT Type Code: ????
Purpose: Serve as a top-level directory
Size: Small is often okay

This is used when a partition contains dm-verity integrity data.

Root Verity (x32 x86) d13c5d3b-b5d1-422a-b29f-9454fdc89d76
Root Verity (x64) 2c7357ed-ebd2-46d9-aec1-23d437ec2bf5
Root Verity (32-bit ARM) 7386cdf2-203c-47a9-a498-f2ecce45a2d6
Root Verity (64-bit ARM/AArch64) df3300ce-d69f-4c92-978c-9bfb0f38d820
Root Verity (“Intel Itanium”/“Intel Architecture 64” (“IA64”)) 86ed10d5-b607-45bb-8957-d350f23d0571
[#gptlnxsw]:

Linux Swap

GUID Partition Type: 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f
GPT Type Code: 8200
Purpose: Serve as a top-level directory
Size: Can vary. (See ideal swap/page size.)

Perhaps this GUID Partition Type of 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f was chosen by FreeDesktop.org's “The Discoverble Partitions Specification”.

[#gptunuse]:

Unused

GUID Partition Type: 00000000-0000-0000-0000-000000000000
GPT Type Code: ????

This “GUID Partition Type” identifier is all zeros.

[#gptlxhom]: /home/ for Linux-based OS
GUID Partition Type: 933ac7e1-2eb4-4f13-b844-0e14e2aef915
GPT Type Code: 8302
Purpose: Store data meant for use by individual user accounts
Size: Can vary. On many systems, excessively small (e.g., 1 Megabyte) may be perfectly fine.

Perhaps this GUID Partition Type of 933ac7e1-2eb4-4f13-b844-0e14e2aef915 was chosen by FreeDesktop.org's “The Discoverble Partitions Specification”.

[#gptlxsrv]:

/srv/ for Linux-based OS

GUID Partition Type: 3b8f8425-20e0-4f3b-907f-1a25a76f98e8
GPT Type Code: 8306
Purpose: Store data meant for use by services provided by the computer
Size: Can vary.
Purpose

The single authoritative reference that is probably most widely-recognized to define the purpose of the /srv/ directory may be the FHS.

For further detail, perhaps check out this site's LX0-103 / “LPIC-1” Version 4 tutorial.)

Basically, the purpose is to store data meant for use by services which are both provided by a computer, and provided by using software that came bundled with the operating system. For data intended for software that has been added after the operating system has been installed, /opt/ may be more appropriate instead (and, therefore, would not belong on the partition using the GUID Partition Type of 3b8f8425-20e0-4f3b-907f-1a25a76f98e8).

Perhaps this GUID Partition Type of 3b8f8425-20e0-4f3b-907f-1a25a76f98e8 was chosen by FreeDesktop.org's “The Discoverble Partitions Specification”.

[#gptlxbdp]:

Linux computer's Basic Data Partitions

Linux Basic Data Partition
GUID Partition Type: 0FC63DAF-8483-4772-8E79-3D69D8477DE4
GDisk Type Code: 8300
Purpose: Data under Linux that doesn't have a more specific GUID type code reserved
Size: Varies
Multiple codes

Newer versions of Linux-based operating systems may be prone to use 0FC63DAF-8483-4772-8E79-3D69D8477DE4. Older versions may have used EBD0A0A2-B9E5-4433-87C0-68B6B72699C7. This was considered bad because Microsoft operating systems would recognize that as a partition type that the Microsoft operating system should interact with.

Using the GPT Linux Filesystem Data Type Code (by Rod Smith, of gdisk) notes: computers that used the same GUID for Microsoft operating systems and Linux operating systems were frequently more “vulnerable to accidental destruction of their Linux installations from Windows.”

Rod Smith's answer to a question to john smith's AskUbuntu.com question called “GDisk Hex Codes” notes, “ certain Windows tools would think the Linux partition was a damaged or un-initialized Windows partition and offer to prepare it. User error at this prompt would be disastrous.”

[#gptlxmsp]:

Microsoft Partition GUIDs

GUID Partition Type: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
GDisk Type Code: ????
Purpose: Older systems ; Recommended: to Convert to the newer GUID Type 0FC63DAF-8483-4772-8E79-3D69D8477DE4 instead
Size: Varies

This was used until Rod Smith, creator of gdisk, started recommending that a new code gets used instead.

Seeing GPT partition in Microsoft Windows

In the opinion of this author, the best way to start seeing information about the partitions on a drive is with DiskPart. Granted, the WMIC program can also be used to see a lot of information, and the WMIC program is much more versatile because that same program can be used to gather lots of other information (including details related to topics that are quite unrelated to drives/partitions). The WMIC program may even look promising as you learn that there are multiple ways to use it, and the different ways can provide different details.

However, DiskPart provides some key details in a more straightforward manner, and so starting with that is recommended.

DiskPart w/ GPT

In DiskPart, start by using “LIST DISK”.

Then, you can list the partitions with LIST PARTITION.

The following demonstrates trying to list a partition too early (because no disk was selected yet), looking at available disks, and then looking at partitions on that disk.

diskpart

The program may open up in a new window.


Microsoft DiskPart version 10.0.17134.1

Copyright (C) Microsoft Corporation.
On computer: ComputerName

DISKPART> LIST PARTITION

There is no disk selected to list partitions.
Select a disk and try again.

DISKPART> LIST DISK
  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          ### GB   ### GB        *

DISKPART> SELECT DISK 0

Disk 0 is now the selected disk.

DISKPART> LIST PARTITION

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    System             260 MB  1024 KB
  Partition 2    Reserved            16 MB   261 MB
(Other partitions...)

DISKPART>

When listing disks, partitions, or volumes, you may see one of the items has an asterisk in the left corner. That asterisk simply identifies that item as being selected (with the “DISKPART>” prompt's “SELECT” command).

Common Partition Details

Here are some traits that are likely to be found on many computer systems:

ESP

On the disk that boots your computer, you are likley to have an ESP partition (especially if using (U)EFI). When using LIST PARTITION, this partition will show a Type of System. The ESP is likely the first partition, so the offset will be the lowest of all the partitions on the disk.

DISKPART> LIST PARTITION

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    System             260 MB  1024 KB

If you use the SELECT PARTITION command, and then choose DETAIL PARTITION, you may find:

DISKPART> DETAIL PARTITION

Type    : c12a7328-f81f-11d2-ba4b-00a0c93ec93b
Hidden  : Yes
Required: No
Attrib  : 0X8000000000000000
Offset in Bytes: 1048576


  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
* Volume 5         Windows      NTFS   Partition    512 GHealthy    System

DISKPART>

The “System” is a clear indication that this is the ESP drive that was used when starting the system.

MSR

This may be quite distinctive in mulitple ways. First, when listing the partitions, it shows a Type of Reserved. A recognized size may also be some indication that this is likely an MSR partition. The size may be 16MB for a Windows 10 system, or other common values of 32MB or 128MB.

Sample:

DISKPART> LIST PARTITION

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
(Other partition(s)...)
  Partition 2    Reserved            16 MB   261 MB
(Other partitions...)

DETAIL PARTITION may show:

DISKPART> DETAIL PARTITION

Type    : e3c9e316-0b5c-4db8-817d-f92df00215ae
Hidden  : Yes
Required: No
Attrib  : 0X8000000000000000
Offset in Bytes: 273678336

There is no volume associated with this partition.

DISKPART>

Note that while many other partition types will show some volume information after showing the offset in bytes, this partition does not, because no recognized “volume” information was found.

That "Hidden" may be quite effective. The MSR won't show up in many other views.

Windows Boot

Using LIST PARTITION shows this Type column has a value of “Primary”. In this way, it looks quit similar to a typical data drive.

DISKPART> LIST PARTITION

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
(Other partition(s)...)
  Partition 3    Primary            512 GB   277 MB
(Other partitions...)

Showing the partition detail may look something like this:

DETAIL PARTITION may show:

DISKPART> DETAIL PARTITION

Type    : ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
Hidden  : No
Required: No
Attrib  : 0000000000000000
Offset in Bytes: 290455552

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
* Volume 1     C   Windows      NTFS   Partition    512 GHealthy    Boot

DISKPART>

The biggest indicator that the partition is the Microsoft Windows Boot drive is the word “Boot” in the “Info” column. The next-most-significant clue is likely the Drive Letter being C:. Being “Volume 1” (when looking at a partition other than partition 1) might also be an indicator too, although perhaps less reliable.

Windows Basic Data Partition

Standard data drives will include a lot of details as the example Microsoft Windows “Boot” drive (which is the prior example shown in more detail), with the key notable difference being that they don't show “Boot” in the “Info” column. (Instead, the “Boot” column is simply left blank.)

Microsoft Windows Recovery Environment
DISKPART> LIST PARTITION

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
(Other partition(s)...)
  Partition 5    Recovery          1000 MB   911 MB
(Other partitions...)

The strongest easy indicator is looking at the reported value in LIST PARTITION's “Type” column, as shown above. If there is still any remaining question, you can also look at LIST PARTITION's “type” row, as shown below, and see if that matches de94bba4-06d1-4d40-a16a-bfd50179d6ac (as shown in the upcoming documented example).

DETAIL PARTITION may show:

DISKPART> DETAIL PARTITION

Type    : de94bba4-06d1-4d40-a16a-bfd50179d6ac
Hidden  : No
Required: Yes
Attrib  : 000000000000000001
Offset in Bytes: 978290999296

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
* Volume 6         WINRE_DRV    NTFS   Partition   1000 MHealthy    Hidden

DISKPART>

Now that you've been able to see what partitions exist, the next recommended step is to get a quick overview of the volumes.

DISKPART> LIST VOLUME

  Volume ### &Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     E                       DVD-ROM         0 B  No Media
* Volume 1     C   Windows      NTFS   Partition    512 GB  Healthy    Boot
  Volume 2     D   LENOVO       NTFS   Partition     25 GB  Healthy
  Volume 3     R   WINRE_DRV    NTFS   Partition   1000 MB  Healthy
  Volume 4     L   LENOVO_PART  NTFS   Partition     18 GB  Healthy
  Volume 5     S   SYSTEM_DRV   FAT32  Partition    260 MB  Healthy    System

DISKPART>

That's quite a bit of useful information about volumes, and some people may appreciate having that be the first thing. Not only does it show information about the fixed disks, but it also reports a DVD ROM drive (perhaps because that drive has a drive letter?). However, this doesn't show all of the partitions. For instnace, the MSR partition is not visible here, at all. Also, the OEM drive, which did not have a detectable volume, doesn't show up here. So, while this is a nice batch of information being shown quickly, realize that this information is partial. Some details are missing from this view. Namely, especially, some partitions are missing from this view.

(Note: Some of the above sample drive letters were assigned based on examples from Microsoft Documentation: “UEFI/GPT-based hard drive partitions”, section called “Sample files: configure drive partitions by using Windows PE and DiskPart scripts”. You may find that the system drive (S: in the above example) and recovery drives (R: and L: in the above example) are not assigned, and so they may have a blank column.

Making some changes
Mounting a drive

First, make sure the partition is selected. (So, DETAIL PARTITION should show this partition.)

To assign it a drive letter:

ASSIGN LETTER=DriveLetter

(No colon after the drive letter.)

e.g.:

DISKPART> ASSIGN LETTER=S

DiskPart successfully removed the drive letter or mount point.

DISKPART>

Then, if you leave that assigned, various online resources indicate the drive will keep that drive letter even after a reboot. However, that likely only happens if the nodefaultdriveletter (“No Default Drive Letter”) attribute is false.

A book titled “Windows Administration at the Command Line”, “for Windows Vista, Windows 2003, Windows XP, andWindows 2000”, by John Paul Meuller, stated, “The system won't allow you to assign drive letters to system volumes, boot volumes, or volumes that contain the paging file. In addition, you can't assign a drive letter to an Original Equipment Manufacturer (OEM) partition or any GUID Partition Table (GPT) partition other than a basic data partition.” At least some of that is false in Windows 10.

Unmounting a drive

If it has a drive letter:

REMOVE LETTER=DriveLetter

(No colon after the drive letter.)

e.g.:

DISKPART> REMOVE LETTER=S

DiskPart successfully removed the drive letter or mount point.

DISKPART>
Handling attributes
DISKPART> LIST VOLUME

  Volume ### &Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     E                       DVD-ROM         0 B  No Media
* Volume 1     C   Windows      NTFS   Partition    512 GB  Healthy    Boot
  Volume 2     D   LENOVO       NTFS   Partition     25 GB  Healthy
  Volume 3     R   WINRE_DRV    NTFS   Partition   1000 MB  Healthy
  Volume 4     L   LENOVO_PART  NTFS   Partition     18 GB  Healthy
  Volume 5     S   SYSTEM_DRV   FAT32  Partition    260 MB  Healthy    System

DISKPART>SELECT VOLUME 5

Volume 5 is the selected volume.

DISKPART>ATTRIBUTES VOLUME

Virtual Disk Service error:
The object is not found.


DISKPART>

Hmm, that didn't seem to work too well. Perhaps that is because the drive was a FAT32 drive.

DISKPART>SELECT VOLUME 3

Volume 3 is the selected volume.

DISKPART>ATTRIBUTES VOLUME
Read-only              : No
Hidden                 : No
No Default Drive Letter: Yes
Shadow Copy            : No

DISKPART>ATTRIBUTES VOLUME CLEAR NODEFAULTDRIVELETTER

Volume attributes cleared successfully.

DISKPART>

However, some preliminary testing showed a case where the volume attribute actually wasn't cleared successfully, despite that message. So be sure to check the results.

WMIC w/ GPT

Relevant objects may include:

  • PATH Win32_DiskPartition
  • LOGICALDISK
  • VOLUME
  • PARTITION
  • DISKDRIVE
WARNING: UNVERIFIED CONTENT

Warning: The following information is preliminary. This may also contain information about getting information about disks. Some of this information may move at a later time.

There are multiple WMIC objects that can provide details about partitions on disks. Although it might have been more convenient if one object could be used to get a lot of the relevant information, at least there is enough overlap so you can get some details about a partition, and then get other details about the same partition, and match up those details so that you can know which partition the details are about.

C:\> WMIC PATH Win32_DiskPartition Get Caption,DeviceID,Name
Caption                DeviceID               Name
Disk #0, Partition #0  Disk #0, Partition #0  Disk #0, Partition #0
Disk #0, Partition #1  Disk #0, Partition #1  Disk #0, Partition #1
Disk #0, Partition #2  Disk #0, Partition #2  Disk #0, Partition #2
Disk #0, Partition #3  Disk #0, Partition #3  Disk #0, Partition #3
Disk #0, Partition #4  Disk #0, Partition #4  Disk #0, Partition #4
Disk #0, Partition #5  Disk #0, Partition #5  Disk #0, Partition #5


C:\>

Hmm, it looks like the Caption, DeviceID, and Name are all the same. Let's confirm that, just to make sure there aren't any minor differences that are being overlooked.

C:\> WMIC PATH Win32_DiskPartition WHERE 'Caption=DeviceID' Get Caption,DeviceID
Caption                DeviceID               Name
Disk #0, Partition #0  Disk #0, Partition #0  Disk #0, Partition #0
Disk #0, Partition #1  Disk #0, Partition #1  Disk #0, Partition #1
Disk #0, Partition #2  Disk #0, Partition #2  Disk #0, Partition #2
Disk #0, Partition #3  Disk #0, Partition #3  Disk #0, Partition #3
Disk #0, Partition #4  Disk #0, Partition #4  Disk #0, Partition #4
Disk #0, Partition #5  Disk #0, Partition #5  Disk #0, Partition #5


C:\> WMIC PATH Win32_DiskPartition WHERE 'Caption^<^>DeviceID' Get Caption,DeviceID,Name
No Instance(s) Available.


C:\> WMIC PATH Win32_DiskPartition WHERE 'Caption=Name' Get Caption,Name
Caption                DeviceID               Name
Disk #0, Partition #0  Disk #0, Partition #0  Disk #0, Partition #0
Disk #0, Partition #1  Disk #0, Partition #1  Disk #0, Partition #1
Disk #0, Partition #2  Disk #0, Partition #2  Disk #0, Partition #2
Disk #0, Partition #3  Disk #0, Partition #3  Disk #0, Partition #3
Disk #0, Partition #4  Disk #0, Partition #4  Disk #0, Partition #4
Disk #0, Partition #5  Disk #0, Partition #5  Disk #0, Partition #5


C:\> WMIC PATH Win32_DiskPartition WHERE 'Caption^<^>Name' Get Caption,Name
No instances available.


C:\>

Note: The caret character (“^”) is used as an escape character interpreted by the shell. As noted by Common Information Model documentation, the caret is not needed by the shell if using quotation marks rather than apostrophes.

So, the above confirmed that when using the Win32_DiskPartition object, the Caption, DeviceID, and Name properties all had the same values.

A couple of other values may also just show some of the same information:

C:\> WMIC PATH Win32_DiskPartition WHERE 'Caption=DeviceID' Get Caption,DiskIndex,Index
Caption               DiskIndex  Index
Disk #0, Partition #0  0          0
Disk #0, Partition #1  0          1
Disk #0, Partition #2  0          2
Disk #0, Partition #3  0          3
Disk #0, Partition #4  0          4
Disk #0, Partition #5  0          5


C:\>

Going forward, many of these examples may use both DiskIndex and Index because that results in less field width being used up. (The DiskIndex title is 8 characters longer than the typical field length, and Index is four characters longer than the typical field length, but those 12 extra characters are still shorter than the 21 character length of a Caption, DeviceID, or Name field that has a value like “Disk #0, Partition #0”. Having shorter field lengths can be used when using the default output style, which is the same as using “/FORMAT:TABLE”.)

Now, let's get a bit more information from the disks, other than just the names.

C:\> WMIC PATH Win32_DiskPartition Get Bootable,BootPartition,Caption,Description,Type
Bootable  BootPartition  Description      DiskIndex  Index  Type
TRUE      TRUE           GPT: System      0          0      GPT: System
FALSE     FALSE          GPT: Basic Data  0          1      GPT: Basic Data
FALSE     FALSE          GPT: Basic Data  0          2      GPT: Basic Data
FALSE     FALSE          GPT: Unknown     0          3      GPT: Unknown
FALSE     FALSE          GPT: Unknown     0          4      GPT: Unknown
FALSE     FALSE          GPT: Unknown     0          5      GPT: Unknown


C:\>

We now see some more information, including some differences between some of the partitions. It looks like the Description and Type fields may be identical. Let's see how provable that is:

C:\> WMIC PATH Win32_DiskPartition WHERE 'Description=Type' Get Bootable,BootPartition,Caption,Description,Type
Bootable  BootPartition  Description      DiskIndex  Index  Type
TRUE      TRUE           GPT: System      0          0      GPT: System
FALSE     FALSE          GPT: Basic Data  0          1      GPT: Basic Data
FALSE     FALSE          GPT: Basic Data  0          2      GPT: Basic Data
FALSE     FALSE          GPT: Unknown     0          3      GPT: Unknown
FALSE     FALSE          GPT: Unknown     0          4      GPT: Unknown
FALSE     FALSE          GPT: Unknown     0          5      GPT: Unknown


C:\> WMIC PATH Win32_DiskPartition WHERE 'Description^<^*gt;Type' Get Bootable,BootPartition,Caption,Description,Type
No Instance(s) Available


C:\>

Okay, since those fields are identical.

Other types that have been seen include “Unknown” or “Installable File System”. (Those were seen on a system that did not have GPT partitions listed. On that system, Description and Type were the same for each partition.)

Since we have some duplicate fields, let's look at another detail:

C:\> WMIC PATH Win32_DiskPartition Get Bootable,BootPartition,Caption,Description,PrimaryPartitionType
Bootable  BootPartition  Description      DiskIndex  Index  PrimaryPartition
TRUE      TRUE           GPT: System      0          0      TRUE
FALSE     FALSE          GPT: Basic Data  0          1      TRUE
FALSE     FALSE          GPT: Basic Data  0          2      GPT: TRUE
FALSE     FALSE          GPT: Unknown     0          3      GPT: FALSE
FALSE     FALSE          GPT: Unknown     0          4      GPT: FALSE
FALSE     FALSE          GPT: Unknown     0          5      GPT: FALSE


C:\>

We now see that out of these six partitions, one is the boot partition and, of course, that one is bootable. This is the drive's ESP (Exensible Firmware Interface System Partition), which seemed likely based on the Description/Type of “GPT: System”.

The others are not bootable. The ESP and the partitions identified as “GPT: Basic Data” are listed as Primary Partitions.

So, we are starting to see some differences between some of the partitions. Still, the only differences we see between the partitions with Index 1 and Index 2 are the Index number, and the only differences between the partitions with Index numbers of 3, 4, and 5 are the Index number. It would be nice to have some additional options to identify the drives. Fortunately, we can get some:

C:\> WMIC PATH Win32_DiskPartition Get BlockSize,DiskIndex,Index,NumberOfBlocks,Size,StartingOffset
BlockSize  DiskIndex  Index  NumberOfBlocks  Size          StartingOffset
512        0          0      532480          272629760     1048576
512        0          1      1073741824      549755813888  290455552
512        0          2      52428800        26843545600   951447453696
512        0          3      2048000         1048576000    978290999296
512        0          4      38703104        19815989248   979339575296
512        0          5      2048000         1048576000    999155564544


Let's analyze that a moment:

In every case, the size in the “Block size” column, mutiplied by the number in the “NumberOfBlocks”, equals the number in the Size column. (Following are the actual mathematical statements showing this.)
512x532480=272,629,760
512x1,073,741,824=549,755,813,888
512x52,428,800=26,843,545,600
512x2048000=1,048,576,000
512x38703104=19,815,989,248
512x2048000=1,048,576,000

Also, may often find that one partition's StartingOffset, plus the Partition's Size, will often equal the next Partition's Starting Offset.

Index 2: 26843545600+951447453696=978290999296
Index 3: 1048576000+978290999296=979339575296
Index 4: 19815989248+979339575296=999155564544

Okay, we've now figured out that this computer is using one disk (as the DiskIndex is always the same), and that this is using GPT, how many partitions there are, and their sizes. Let's see what else we can figure out from a different object.

Actually, we have a couple of other objects we can choose from. They have quite a bit of information that are similar to each other:

C:\> WMIC LOGICALDISK Get Caption,Compressed,DriveType,FileSystem,FreeSpace,Name,SupportsDiskQuotas,SupportsFileBasedCompression
Caption  Compressed  DriveType  FileSystem  FreeSpace     Name  SupportsDiskQuotas  SupportsFileBasedCompression
C:       FALSE       3          NTFS        371965210624  C:    FALSE               TRUE
D:       FALSE       3          NTFS        24878272512   D:    FALSE               TRUE
E:                   5                                    E:


C:\> WMIC VOLUME WHERE 'Caption^<^>DeviceID and DeviceID^<^>Name' Caption,Compressed,DriveType,FileSystem,FreeSpace,Name,SupportsDiskQuotas,SupportsFileBasedCompression
Caption  Compressed  DriveType  FileSystem  FreeSpace     Name  SupportsDiskQuotas  SupportsFileBasedCompression
C:\      FALSE       3          NTFS        371965210624  C:\   TRUE                TRUE
D:\      FALSE       3          NTFS        24878272512   D:\   TRUE                TRUE
E:\                  5                                    E:\


C:\>

Hmm, that shows a lot of identical information. It is interesting, though, that SupportsDiskQuotas gives different values.

Besides those fields with identical names and identical or similar values (usually), there are some properties that have different names, but still similar values:

WMIC LOGICALDISK Get MaximumComponentLength,Size,VolumeSerialNumber

WMIC VOLUME WHERE 'Caption^<^>DeviceID and DeviceID^<^>Name'  Get Capacity,MaximumFileNameLength,SerialNumber

However, these objects (LOGICALDISK and VOLUME) are not totally identical. Some information may be available in one, and not the other.

Here are some notes from a Windows 10 machine:

(This information has not been double-checked at the time of this writing.)

Blank values on both:
	Availability
	ConfigManagerErrorCode
	ConfigManagerUserConfig
	ErrorCleared
	ErrorDescription
	ErrorMethodology
	InstallDate
	LastErrorCode
	NumberOfBlocks
	PNPDeviceID
	PowerManagementCapabilities
	PowerManagementSupported
	Purpose
	Status
	StatusInfo				
Identical (and not blank):

	Compressed
	DriveType
	FileSystem
	FreeSpace
	SupportsDiskQuotas
	SupportsFileBasedCompression				
On both, but with slightly or significantly different values:

	Caption
	DeviceID
	Name				
Only on LogicalDisk:

	MaximumComponentLength (but like Volume's MaximumFileNameLength)
	MediaType
	Size (but like LogicalDisk's Capacity)
	VolumeDirty (blank, presumably like Volume's non-blank DirtyBitSet)
	VolumeName
	VolumeSerialNumber (presumably like Volume's SerialNumber, but this is in hexadecimal)				
Only on Volume:

	Automount
	BootVolume
	Capacity (but like Size on LogicalDisk)
	DirtyBitSet (but might be like LogicalDisk's blank VolumeDirty)
	DriveLetter
	IndexingEnabled
	Label
	MaximumFileNameLength (but like LogicalDisk's MaximumComponentLength)
	PageFilePresent
	SerialNumber (presumably like LogicalDisk's VolumeSerialNumber, but this is in decimal)				
On LogicalDisk with Info, and Volume without info:

	Access
	CreationClassName
	Description
	SystemCreationClassName
	SystemName				
On Volume with Info, and LogicalDisk without info:

	BlockSize
	QuotesEnabled
	QuotasIncomplete
	QuotasRebuilding				

This gets some info from VOLUME, showing size ("capacity") and some details that aren't seen in LogicalDisk. This is actual output from a Lenovo-brand laptop:

C:\> WMIC VOLUME Get BootVolume,Capacity,DriveLetter,Label,PageFilePresent
BootVolume  Capacity      DriveLetter  Label        PageFilePresent
TRUE        549755809792  C:           Windows      TRUE
FALSE       26843541504   D:           LENOVO       FALSE
FALSE       268435456                  SYSTEM_DRV   FALSE
FALSE       1048571904                 WINRE_DRV    FALSE
FALSE       19815985152                LENOVO_PART  FALSE
                         E:


C:\>

Hmm, that E: doesn't seem to provide as much information as the other drives. The following will explain why:

C:\> WMIC LOGICALDISK Get Description,DeviceID,MediaType,Size,VolumeName,VolumeSerialNumber
Description,DeviceID,MediaType,Size,VolumeName,VolumeSerialNumber
Description       DeviceID  MediaType  Size          VolumeName  VolumeSerialNumber Local Fixed Disk  C:        12         549755809792  Windows     629B9FE0 Local Fixed Disk  D:        12         26843541504   LENOVO      6A248BCA CD-ROM Disc       E:        11

C:\>

So that's an overview of some of the different information obtainable from different objects. Now, how to match them up?

Well, drives from LogicalDisk and VOLUME should be easy to line up. One way is to look at the Volume's DeviceID property (with GET DeviceID, or even Get ID which will also show the DeviceID) and compare to LogicalDisk's

WMIC VOLUME WHERE 'DriveLetter is not NULL' Get Caption,DriveLetter,Name,SerialNumber,Capacity

...

WMIC LOGICALDISK Get Caption,DeviceID,Name,Size,VolumeSerialNumber

Matching things up with Win32_DiskPartition may be a bit harder. For one disk, this might be somewhat easy:

WMIC WMIC PATH Win32_DiskPartition Get Bootable,BootPartition,DiskIndex,Index
WMIC VOLUME Get BootVolume,DeviceID,SystemVolume

The ESP is likely to show up under Win32_DiskPartition as Bootable=TRUE and BootParittion=TRUE and both Deescription and Type equal to GPT: System, while the Size may be similar to the VOLUME object's Capacity and shows a SystemVolume property of TRUE. (Contrary to what the Win32_DiskPartition's Bootable and BootPartition values would suggest, VOLUME may show this as BootVolume=FALSE, as the VOLUME's BootVolume=TRUE may typically reference where Microsoft Windows was installed, typically the C:.)

The Win32_DiskPartition's PrimaryPartition set to TRUE is likely to be the ESP or a regular mountable drive. So see which devices are primary partitions:

WMIC PATH Win32_DiskPartition Get DiskIndex,Index,PrimaryPartition,Size

ignore the ESP if possible, and match the others with WMIC VOLUME which has a drive letter.

WMIC PATH VOLUME Get Capacity,Driveletter,Name
- or can try to just line up using sizes - can try using Diskpart to help:
DiskPart
DISKPART> LIST VOLUME

This may show details of a fixed disk, and also may include removable media

This may place items with a drive letter first, not necessarily matching the order that things are laid out on the disk.

The "Label" column of this output should match the Label from “ WMIC VOLUME Get Capacity,Label,Name

The "Label" column of this output should match the Label from “ WMIC LOGICALDISK Get Description,DeviceID,Size,VolumeName,VolumeSerialNumber ”, although that may not show some volumes.

DISKPART> LIST Partition

There is no disk selected to list partitions.
Select a disk and try again.

DISKPART> LIST DISK
[Sample Output]
DISKPART> SELECT DISK 0
Possibly more output here too?
DISKPART> LIST PARTITION
[Sample Output]
DISKPART>

By looking at the Offset, you can tell the actual order on disk

DISKPART> DETAIL DISK

The abvoe command shows info similar to using LIST VOLUME

However, if there are multiple drives (including, as an example, a drive related to removable media like a CD-ROM drive), that shouldn't show up, because this just shows details of the selected disk.

DISKPART> LIST VOLUME
[Sample Output]
DISKPART> SELECT VOLUME 3
[Sample Output]
DISKPART> DETAIL VOLUME

...

DISKPART> SELECT PARTITION 1
[Sample Output]
DISKPART> DETAIL PARTITION

The “Offset in Bytes” here should match the StartingOffset from WMIC PATH Win32_DiskPartition Get DiskIndex,Index,Size,StartingOffset

The “Label” column of this output should match the Label from WMIC VOLUME Get Capacity,Label,Name

This shows there should be a way to match WMIC PATH Win32_DiskPartition with WMIC VOLUME.

Old note: One thing to do is to grab the VOLUME's DeviceID (which is different than the LogicalDisk's DeviceID) WMIC VOLUME Get Capacity,DeviceID,DriveLetter WMIC PATH Win32_DiskPartition Get Different results: SupportsDiskQuotas as shown earlier Blocksize 512 per Win32_DiskPartition 4096 per VOLUME

Resources

Microsoft Windows and GPT FAQ (“applies to Windows 10 and Windows Server 2016”, and notes a previous version available at: Microsoft “Previous Versions Documentation”, “Windows and GPT FAQ (updated June 1, 2017, and possibly later). Also, Microsoft had previously published some documentation in the Microsoft Windows Hardware Dev Center: Windows and GPT FAQ Version 1.1 (as archived by the Wayback Machine @ Archive.org from Feburary 19, 2011).

Maybe also MS KB 302873? See: MS KB 302873: Frequently asked questions about the GUID Partitioning Table disk architecture also seems to be a version of the same documentation (having lots of the same details).

Microsoft Documentation: Hard Drives and Partitions