UUID GUID
目 录
1作用
2组成
3应用
目 录
1简介
2格式
3特点
4争议
1、支持2TB以上的大硬盘。
2、每个磁盘的分区个数几乎没有限制。为什么说“几乎”呢？是因为Windows系统最多只允许划分128个分区。不过也完全够用了。
3、分区大小几乎没有限制。又是一个“几乎”。因为它用64位的整数表示扇区号。夸张一点说，一个64位整数能代表的分区大小已经是个“天文数字”了，若干年内你都无法见到这样大小的硬盘，更不用说分区了。
4、分区表自带备份。在磁盘的首尾部分分别保存了一份相同的分区表。其中一份被破坏后，可以通过另一份恢复。
5、每个分区可以有一个名称(不同于卷标)。
|
Windows种类
|
能否读写GPT磁盘
|
能否从GPT磁盘启动
|
|
32位 Windows XP
|
不能。只能看到一个Protective MBR分区
|
不支持
|
|
Windows 2000/NT/9x
|
不能。只能看到一个Protective MBR分区
|
不支持
|
|
64位 Windows XP
|
能
|
只有基于Itanium的系统才能从GPT磁盘启动
|
|
Windows Server 2003 SP1及以上版本
|
能
|
只有基于Itanium的系统才能从GPT磁盘启动
|
|
Windows Vista
|
能
|
只有基于 EFI 的系统支持从GPT磁盘启动
|
|
Windows Server 2008
|
能
|
只有基于 EFI 的系统支持从GPT磁盘启动
|
|
Windows 7
|
能
|
只有基于 EFI 的系统支持从GPT磁盘启动
|
| Windows 8/8.1 | 能 | 只有基于 EFI 的系统支持从GPT磁盘启动 |
注：UUID-Universally Unique IDentifiers全局唯一标识符
一、Linux磁盘分区UUID的获取方法
1、[san@localhost ~]$ ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 2010-01-18 02:18 0733f5c1-cb85-4f98-9d4f-122cfcee9806 -> ../../sdc1
lrwxrwxrwx 1 root root 10 2010-01-18 01:13 3754-1BDB -> ../../sda5
lrwxrwxrwx 1 root root 10 2010-01-18 01:13 41a18221-6b1f-4ca2-9bc3-dc353c87d932 -> ../../sda9
lrwxrwxrwx 1 root root 10 2010-01-18 01:13 57183ff9-d4a5-4623-a47f-f8f17339be03 -> ../../sda7
lrwxrwxrwx 1 root root 10 2010-01-18 01:13 6bdf487f-cad7-4197-b0d9-4ddc6df1de2d -> ../../sda8
lrwxrwxrwx 1 root root 10 2010-01-18 01:13 ae6dcc02-3f7f-47cc-8a6e-e29218b4d345 -> ../../sda6
lrwxrwxrwx 1 root root 10 2010-01-18 01:13 CC47-2A04 -> ../../sda1
lrwxrwxrwx 1 root root 10 2010-01-18 02:18 d2154d3e-3006-4a05-a134-f721145f1670 -> ../../sdc2
lrwxrwxrwx 1 root root 10 2010-01-18 02:18 df974270-dbba-4f87-8121-427636dab396 -> ../../sdc3
lrwxrwxrwx 1 root root 10 2010-01-18 01:52 f535fef8-f392-4c84-8e7a-85915d9179fb -> ../../sdb1
VS:
lrwxrwxrwx 1 root root 10 2010-01-18 02:25 0733f5c1-cb85-4f98-9d4f-122cfcee9806 -> ../../sdb1
lrwxrwxrwx 1 root root 10 2010-01-18 01:13 3754-1BDB -> ../../sda5
lrwxrwxrwx 1 root root 10 2010-01-18 01:13 41a18221-6b1f-4ca2-9bc3-dc353c87d932 -> ../../sda9
lrwxrwxrwx 1 root root 10 2010-01-18 01:13 57183ff9-d4a5-4623-a47f-f8f17339be03 -> ../../sda7
lrwxrwxrwx 1 root root 10 2010-01-18 01:13 6bdf487f-cad7-4197-b0d9-4ddc6df1de2d -> ../../sda8
lrwxrwxrwx 1 root root 10 2010-01-18 01:13 ae6dcc02-3f7f-47cc-8a6e-e29218b4d345 -> ../../sda6
lrwxrwxrwx 1 root root 10 2010-01-18 01:13 CC47-2A04 -> ../../sda1
lrwxrwxrwx 1 root root 10 2010-01-18 02:25 d2154d3e-3006-4a05-a134-f721145f1670 -> ../../sdb2
lrwxrwxrwx 1 root root 10 2010-01-18 02:25 df974270-dbba-4f87-8121-427636dab396 -> ../../sdb3
2、通过blkid命令
[san@localhost ~]$ blkid /dev/sdb1
/dev/sdb1: LABEL="SAN " UUID="f535fef8-f392-4c84-8e7a-85915d9179fb " TYPE="ext3 "
[san@localhost ~]$ blkid /dev/sda6
/dev/sda6: LABEL="/" UUID="ae6dcc02-3f7f-47cc-8a6e-e29218b4d345 " TYPE="ext3" SEC_TYPE="ext2 "
二、Linux UUID的作用及意义
原因1：它是真正的唯一标志符
UUID为系统中的存储设备提供唯一的标识字符串，不管这个设备是什么类型的。如果你在系统中添加了新的存储设备如硬盘，很可能会造成一些麻烦，比如说启动的时候因为找不到设备而失败，而使用UUID则不会有这样的问题。
原因2：设备名并非总是不变的
自动分配的设备名称并非总是一致的，它们依赖于启动时内核加载模块的顺序。如果你在插入了USB盘时启动了系统，而下次启动时又把它拔掉了，就有可能导致设备名分配不一致。
使用UUID对于挂载移动设备也非常有好处──例如我有一个24合一的读卡器，它支持各种各样的卡，而使用UUID总可以使同一块卡挂载在同一个地方。
原因3：ubuntu中的许多关键功能现在开始依赖于UUID
例如grub──系统引导程序，现在可以识别UUID，打开你的/boot/grub/menu.lst，你可以看到类似如下的语句：
title Ubuntu hardy (development branch), kernel 2.6.24-16-generic
root (hd2,0)
kernel /boot/vmlinuz-2.6.24-16-generic root=UUID=c73a37c8-ef7f-40e4-b9de-8b2f81038441 ro quiet splash
initrd /boot/initrd.img-2.6.24-16-generic
quiet
http://en.wikipedia.org/wiki/GUID_Partition_Table
GUID Partition Table
GUID Partition Table (GPT) is a standard for the layout of the partition table on a physical hard disk, using globally unique identifiers (GUID). Although it forms a part of the Unified Extensible Firmware Interface (UEFI) standard (Unified EFI Forum proposed replacement for the PC BIOS), it is also used on some BIOS systems because of the limitations of MBR partition tables, which use 32 bits for storinglogical block addresses and size information.
As of 2010, most current operating systems support GPT. Some, including OS X and Microsoft Windows, only support booting from GPT partitions on systems with EFI firmware, but FreeBSD and most Linux distributions can boot from GPT partitions on systems with either legacy BIOS firmware interface or EFI.
Contents
[hide]
History[edit]
The widespread MBR partitioning scheme, dating from the early 1980s, imposed limitations which affect the use of modern hardware. One of the main limitations is the usage of 32 bits for storing logical block addresses and size information.
For hard disks with 512-byte sectors, the MBR partition table entries allow up to a maximum of 2 TiB (232×512 Bytes)).[1] GPT allocates 64 bits for logical block addresses and therefore allows a maximum partition size of 264−1 sectors. For disks with 512-byte sectors, that would be 9.4 ZB (9.4 × 1021 bytes) or 8 ZiB−512 bytes (9,444,732,965,739,290,426,880 bytes or 18,446,744,073,709,551,615 (264−1) sectors × 512 (29) bytes per sector).[1][2]
Intel therefore developed a new partition-table format in the late 1990s as part of what eventually became UEFI. The GPT as of 2010 forms a subset of the UEFI specification.[3]
Features[edit]
 |
This section needs additional citations for verification. (July 2013) |
MBR-based partition table schemes insert the partitioning information for (usually) four "primary" partitions in the master boot record (MBR) (which on a BIOS system is also the container for code that begins the process of booting the system). In a GPT, the first sector of the disk is reserved for a "protective MBR" such that booting a BIOS-based computer from a GPT disk is supported, but the boot loader and O/S must both be GPT aware. Regardless of the sector size, the GPT header begins on the second logical block of the device.
Like modern MBRs, GPTs use logical block addressing (LBA) in place of the historical cylinder-head-sector (CHS) addressing. The protective MBR is contained in LBA 0, the GPT header is in LBA 1, and the GPT header has a pointer to the partition table, or Partition Entry Array, typically LBA 2. The UEFI specification[4] stipulates that a minimum of 16,384 bytes, regardless of sector size, be allocated for the Partition Entry Array. On a disk having 512-byte sectors, a partition entry array size of 16,384 bytes and the minimum size of 128 bytes for each partition entry, LBA 34 is the first usable sector on the disk.
Hard disk manufacturers are transitioning to 4,096-byte sectors. As of 2010, the first such drives continue to present 512-byte physical sectors to the OS, so degraded performance can result when the drive's (hidden) internal 4 KiB sector boundaries do not coincide with the 4 KiB logical blocks, clusters and virtual memory pages common in many operating systems and file systems. This is a particular problem on writes when the drive is forced to perform two read-modify-write operations to satisfy a single misaligned 4 KiB write operation.[5] Such a misalignment occurs by default if the first partition is placed immediately after the GPT, as the next block is LBA 34, whereas the next 4 KiB boundary begins with LBA 40.
For backward compatibility with most operating systems before Windows Vista, including DOS, OS/2 and Windows, MBR partitions must always start on track boundaries according to the traditional CHS addressing scheme and end on a cylinder boundary. This even holds true for partitions with emulated CHS geometries (as reflected by the BIOS and the CHS sectors entries in the MBR partition table) or partitions accessed only via LBA. Extended partitions always start on cylinder boundaries as well.
This typically causes the first primary partition to start at LBA 63 on disks accessed via LBA, leaving a gap of 62 sectors with MBR-based disks, sometimes called "MBR gap", "boot track", or "embedding area". That otherwise unused disk space is commonly used by boot loaders such as GRUB for storing their second stages.[6] On older computers using alternative LBA/CHS translation schemes or different extended CHS mappings, with smaller LBA-accessed disks, or on disks accessed via CHS only, the value could be even smaller, although not normally less than LBA 16 on normal hard disks.
Since Windows Vista, the first partition usually starts after a gap of 2,047 sectors at LBA 2,048 as part of its new 1 MiB partition alignment policy, so no large-sector misalignment occurs by default, but serious compatibility problems with older operating systems and disk tools exist.
Drives which boot Intel-based Macs are typically formatted with a GPT, rather than with the Apple Partition Map (APM).
GPT also provides redundancy, writing the GPT header and partition table both at the beginning and at the end of the disk.
If the minimum size of 16,384 bytes is allocated for the partition entry array, and the default size of 128 bytes is used for each partition entry, then the maximum number of partitions is limited to 128.
Legacy MBR (LBA 0)[edit]
Traditionally, in IBM PC compatible systems the first sector of the disk holds the Master Boot Record (MBR), containing the drive's partitioning information and the code of the first stage boot loader for BIOS-based systems. For limited backward compatibility, this sector is still reserved for a MBR in the GPT specification, but it is now used in a way that prevents MBR-based disk utilities from mis-recognizing, and possibly over-writing, GPT disks. This is referred to as a "protective MBR".
A single partition type of EEh, encompassing the entire GPT drive (where "entire" actually means as much of the drive as can be represented in an MBR), is indicated and identifies it as GPT. Operating systems and tools which cannot read GPT disks will generally recognize the disk as containing one partition of unknown type and no empty space, and will typically refuse to modify the disk unless the user explicitly requests and confirms the deletion of this partition. This minimizes accidental erasures. Furthermore, GPT-aware OSes will check the protective MBR and if the enclosed partition type is not of typeEEh or if there are multiple partitions defined on the target device, the device should not be manipulated[dubious ].
While the MBR layout (and also the protective MBR layout) was defined around a sector size of 512 bytes per sector, the actual sector size can be larger on various media such as MO disks or hard disks with Advanced Format. Extra space in the MBR typically remains unused.
If the actual size of the disk exceeds the maximum partition size representable using the legacy 32-bit LBA entries in the MBR partition table, the recorded size of this partition is clipped at the maximum, thereby ignoring the rest of disk. This amounts to a maximum reported size of 2 TiB, assuming a disk with 512 bytes per sector (see 512e). It would result in 16 TiB with 4 KB sectors (4Kn), but since many older operating systems and tools are hard-wired for a sector size of 512 bytes or are limited to 32-bit calculations, exceeding the 2 TiB limit would cause serious compatibility problems.
In operating systems that support GPT-based boot through BIOS services rather than EFI, the first sector is also still used to store the first stage of the bootloader code, but modified to recognize GPT partitions. The boot loader in the MBR must not assume a fixed sector size of 512 bytes / sector.
Apple's Boot Camp Intel based Apple macs software creates a hybrid partition table to allow the booting of Windows (which at the time of Boot Camp's creation did not support GPT or EFI). In this system the protective partition is reduced in size to cover from sector 1 to the sector before the first regular partition included in the hybrid MBR. Additional MBR partitions are then defined to correspond to the next three GPT[citation needed] partitions.
Partition table header (LBA 1)[edit]
The partition table header defines the usable blocks on the disk. It also defines the number and size of the partition entries that make up the partition table. The EFI stipulates a minimum of 16,384 bytes be reserved for the partition table array, so there are 128 partition entries reserved, each 128 bytes long.
The header contains the disk globally unique identifier (GUID). It records its own size and location (always LBA 1!) and the size and location of the secondary GPT header and table (always the last sectors on the disk). Importantly, it also contains a CRC32 checksum for itself and for the partition table, which may be verified by the firmware, bootloader and/or operating system on boot. Because of this, hex editors should not be used to modify the contents of the GPT. Such modification would render the checksum invalid. In this case, the primary GPT may be overwritten with the secondary one by disk recovery software. If both GPTs contain invalid checksums, the disk would be unusable, by software that checks the checksum.
| Offset | Length | Contents |
|---|---|---|
| +0 | 8 bytes | Signature ("EFI PART", 45h 46h 49h 20h 50h 41h 52h 54h) |
| +8 | 4 bytes | Revision (for GPT version 1.0 (through at least UEFI version 2.3.1), the value is 00h 00h 01h 00h) |
| +12 | 4 bytes | Header size in little endian (in bytes, usually 5Ch 00h 00h 00h meaning 92 bytes) |
| +16 | 4 bytes | CRC32 of header (offset +0 up to header size), with this field zeroed during calculation |
| +20 | 4 bytes | Reserved; must be zero |
| +24 | 8 bytes | Current LBA (location of this header copy) |
| +32 | 8 bytes | Backup LBA (location of the other header copy) |
| +40 | 8 bytes | First usable LBA for partitions (primary partition table last LBA + 1) |
| +48 | 8 bytes | Last usable LBA (secondary partition table first LBA - 1) |
| +56 | 16 bytes | Disk GUID (also referred as UUID on UNIXes) |
| +72 | 8 bytes | Starting LBA of array of partition entries (always 2 in primary copy) |
| +80 | 4 bytes | Number of partition entries in array |
| +84 | 4 bytes | Size of a single partition entry (usually 128) |
| +88 | 4 bytes | CRC32 of partition array |
| +92 | * | Reserved; must be zeroes for the rest of the block (420 bytes for a sector size of 512 bytes; but can be more with larger sector sizes) |
| LBA size | Total | |
The values for current and backup LBAs of the primary header should be the second sector of the disk (LBA 1) and the last sector of the disk, respectively. The secondary header at the end of the disk identifies its own table of partition entries, which is located directly before that header.
This table must be referenced relative to LBA 1. This means, that on disks with 4Kn sectors, it does not follow the 512 bytes of the MBR physically (stored in LBA 0) and thereby become part of LBA 0 on disks with larger sector sizes. While the described arrangement happens to occur on disks with 512 bytes per sector, there may be "gaps" of unused space between them on disks with larger sector sizes. If multi-sector reads are performed, the actual sector size must be included in the calculation when referencing this table.
Partition entries[edit]
| Offset | Length | Contents |
|---|---|---|
| 0 | 16 bytes | Partition type GUID |
| 16 | 16 bytes | Unique partition GUID |
| 32 | 8 bytes | First LBA (little endian) |
| 40 | 8 bytes | Last LBA (inclusive, usually odd) |
| 48 | 8 bytes | Attribute flags (e.g. bit 60 denotes read-only) |
| 56 | 72 bytes | Partition name (36 UTF-16LE code units) |
| 128 bytes total |
The GPT uses simple and straightforward entries to describe partitions. The first 16 bytes designate the partition type globally unique identifier (GUID). For example, the GUID for an EFI System partition is {C12A7328-F81F-11D2-BA4B-00A0C93EC93B}. The second 16 bytes contain a GUID unique to the partition. Then follow the starting and ending 64-bit LBAs, partition attributes and partition names. As is the nature and purpose of GUIDs, no central registry is needed to ensure the uniqueness of the GUID partition type designators. The location of the partition entries array on disk is defined in the GPT header.
The GPT header contains a field that specifies the size of a partition table entry. The minimum required is 128 bytes, but implementations must allow for other values (see this warning).
Also, the sector size must not be assumed to be hard-wired to 512 bytes per sector in calculations (see Advanced Format), that is, there can be more than four partition entries in a single sector, and (with possible future much larger partition table entries) it is possible to have a sector hold only a fraction of a partition entry. Except for the first two sectors (LBA 0 and LBA 1), the GPT specification just describes the size and organization of a data structure, not in how many sectors it is stored on disk.
The 64 bits partition table attributes are shared between 48 bits common attributes for all partition types, and 16 bits type-specific attributes.
| Bit | Content |
|---|---|
| 0 | System partition (disk partitioning utilities must preserve the partition as is) |
| 1 | EFI firmware should ignore the content of the partition and not try to read from it |
| 2 | Legacy BIOS bootable (equivalent to active flag (typically bit 7 set) at offset +0h in partition entries of the MBR partition table)[7] |
| 3-47 | Reserved for future use |
| 48-63 | Defined and used by the individual partition type |
Microsoft defines the type-specific attributes for Basic data partition according to this TechNet article as:
| Bit | Content |
|---|---|
| 60 | Read-only |
| 62 | Hidden |
| 63 | Do not automount (i.e., do not assign drive letter) |
Operating System support of GPT[edit]
Hybrid MBRs are non-standard and can be interpreted in different ways by different OSes.[8] Unless otherwise noted, OSes provide precedence to the GPT data when a hybrid MBR configuration is encountered.
The term No native support on this arch and version. should be understood this way:
- Not supported as data disk,[9] only known legacy partitions found in protective MBR are accessible via the OS. Detachable disks: only support for MBR partitioning; No access with end user applications. GPT contained raw data is accessible with third-party administrator tools for low level disk access. True file system level support in read or read-write form might be subject of software from a third-party vendor.
UNIX and UNIX-like operating systems[edit]
| OS family | Version or edition | Platform | Read and write support | Boot support | Note |
|---|---|---|---|---|---|
| FreeBSD | Since 7.0 | IA-32, x86-64 | Yes | Yes | In a hybrid configuration, both GPT and MBR partition identifiers may be used. |
| Linux | Most of the x86 Linux distributions |
IA-32, x86-64 | Yes | Yes | New tools such as gdisk,[11] GNU Parted,[12][13] util-linux v2.23+ fdisk,[14][15] Syslinux, GRUB 0.96 + patchesand GRUB 2 have been GPT-enabled. |
| Mac OS X | Since 10.4.0 (some features since 10.4.6)[16] | IA-32, x86-64 | Yes | Yes | Only Intel Macintosh computers can boot from GPT. |
| MidnightBSD | Since 0.4-CURRENT | IA-32, x86-64 | Yes | Requires BIOS | In a hybrid configuration, both GPT and MBR partition identifiers may be used. |
| Solaris | Since Solaris 10 | IA-32, x86-64,SPARC | Yes | Yes | [17] |
| HP-UX | Since HP-UX 11.20 | IA-64 | Yes | Yes | [18] |
Windows: 32-bit versions[edit]
Microsoft does not support EFI on 32-bit platforms, and therefore does not allow booting from GPT partitions.
| OS version | Release date | Platform | Read or write support | Boot support | Note |
|---|---|---|---|---|---|
| Windows XP | 2001-10-25 | IA-32 | No | No | |
| Windows Server 2003 | 2003-04-24 | IA-32 | No | No | |
| Windows Server 2003 SP1 | 2005-03-30 | IA-32 | Yes | No | MBR takes precedence in hybrid configuration[8] |
| Windows Vista | 2006-07-22 | IA-32 | Yes | No | MBR takes precedence in hybrid configuration[8] |
| Windows Server 2008 | 2008-02-27 | IA-32 | Yes | No | MBR takes precedence in hybrid configuration[8] |
| Windows 7 | 2009-10-22 | IA-32 | Yes | No | MBR takes precedence in hybrid configuration[8] |
| Windows 8 | 2012-08-01 | IA-32 | Yes | No | MBR takes precedence in hybrid configuration[8] |
Windows: 64-bit versions[edit]
| OS version | Release date | Platform | Read and write support | Boot support | Note |
|---|---|---|---|---|---|
| Windows XP Professional x64 Edition Windows Server 2003 |
2005-04-25[19] | x64 | Yes | No | MBR takes precedence in hybrid MBR configuration[8] |
| Windows Server 2003 | 2005-04-25 | IA-64 | Yes | Yes | MBR takes precedence in hybrid MBR configuration[8] |
| Windows Vista | 2006-07-22 | x64 | Yes | Requires UEFI | MBR takes precedence in hybrid configuration[8] |
| Windows Server 2008 | 2008-02-27 | x64 | Yes | Requires UEFI | MBR takes precedence in hybrid configuration[8] |
| Windows Server 2008 | 2008-02-27 | IA-64 | Yes | Yes | MBR takes precedence in hybrid configuration[8] |
| Windows 7 Windows Server 2008 R2 |
2009-10-22 | x64 | Yes | Requires UEFI | MBR takes precedence in hybrid configuration.[8] |
| Windows Server 2008 R2 | 2009-10-22 | IA-64 | Yes | Yes | MBR takes precedence in hybrid configuration[8] |
| Windows 8 Windows Server 2012 |
2012-08-01 | x64 | Yes | Requires UEFI | MBR takes precedence in hybrid configuration.[8] |
Partition type GUIDs[edit]
| Assoc. OS | Partition type | Globally unique identifier (GUID)[A] |
|---|---|---|
| (None) | Unused entry | 00000000-0000-0000-0000-000000000000 |
| MBR partition scheme | 024DEE41-33E7-11D3-9D69-0008C781F39F | |
| EFI System partition | C12A7328-F81F-11D2-BA4B-00A0C93EC93B | |
| BIOS Boot partition[B] | 21686148-6449-6E6F-744E-656564454649 | |
| Intel Fast Flash (iFFS) partition (for Intel Rapid Start technology)[20][21] | D3BFE2DE-3DAF-11DF-BA40-E3A556D89593 | |
| Windows | Microsoft Reserved Partition (MSR) | E3C9E316-0B5C-4DB8-817D-F92DF00215AE |
| Basic data partition[C] | EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 | |
| Logical Disk Manager (LDM) metadata partition | 5808C8AA-7E8F-42E0-85D2-E1E90434CFB3 | |
| Logical Disk Manager data partition | AF9B60A0-1431-4F62-BC68-3311714A69AD | |
| Windows Recovery Environment | DE94BBA4-06D1-4D40-A16A-BFD50179D6AC | |
| IBM General Parallel File System (GPFS) partition | 37AFFC90-EF7D-4E96-91C3-2D7AE055B174 | |
| HP-UX | Data partition | 75894C1E-3AEB-11D3-B7C1-7B03A0000000 |
| Service Partition | E2A1E728-32E3-11D6-A682-7B03A0000000 | |
| Linux | Linux filesystem data[C] | 0FC63DAF-8483-4772-8E79-3D69D8477DE4 |
| RAID partition | A19D880F-05FC-4D3B-A006-743F0F84911E | |
| Swap partition | 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F | |
| Logical Volume Manager (LVM) partition | E6D6D379-F507-44C2-A23C-238F2A3DF928 | |
| /home partition | 933AC7E1-2EB4-4F13-B844-0E14E2AEF915 | |
| Reserved | 8DA63339-0007-60C0-C436-083AC8230908 | |
| FreeBSD | Boot partition | 83BD6B9D-7F41-11DC-BE0B-001560B84F0F |
| Data partition | 516E7CB4-6ECF-11D6-8FF8-00022D09712B | |
| Swap partition | 516E7CB5-6ECF-11D6-8FF8-00022D09712B | |
| Unix File System (UFS) partition | 516E7CB6-6ECF-11D6-8FF8-00022D09712B | |
| Vinum volume manager partition | 516E7CB8-6ECF-11D6-8FF8-00022D09712B | |
| ZFS partition | 516E7CBA-6ECF-11D6-8FF8-00022D09712B | |
| Mac OS X | Hierarchical File System Plus (HFS+) partition | 48465300-0000-11AA-AA11-00306543ECAC |
| Apple UFS | 55465300-0000-11AA-AA11-00306543ECAC | |
| ZFS[D] | 6A898CC3-1DD2-11B2-99A6-080020736631 | |
| Apple RAID partition | 52414944-0000-11AA-AA11-00306543ECAC | |
| Apple RAID partition, offline | 52414944-5F4F-11AA-AA11-00306543ECAC | |
| Apple Boot partition | 426F6F74-0000-11AA-AA11-00306543ECAC | |
| Apple Label | 4C616265-6C00-11AA-AA11-00306543ECAC | |
| Apple TV Recovery partition | 5265636F-7665-11AA-AA11-00306543ECAC | |
| Apple Core Storage (i.e. Lion FileVault) partition | 53746F72-6167-11AA-AA11-00306543ECAC | |
| Solaris | Boot partition | 6A82CB45-1DD2-11B2-99A6-080020736631 |
| Root partition | 6A85CF4D-1DD2-11B2-99A6-080020736631 | |
| Swap partition | 6A87C46F-1DD2-11B2-99A6-080020736631 | |
| Backup partition | 6A8B642B-1DD2-11B2-99A6-080020736631 | |
| /usr partition[D] | 6A898CC3-1DD2-11B2-99A6-080020736631 | |
| /var partition | 6A8EF2E9-1DD2-11B2-99A6-080020736631 | |
| /home partition | 6A90BA39-1DD2-11B2-99A6-080020736631 | |
| Alternate sector | 6A9283A5-1DD2-11B2-99A6-080020736631 | |
| Reserved partition | 6A945A3B-1DD2-11B2-99A6-080020736631 | |
| 6A9630D1-1DD2-11B2-99A6-080020736631 | ||
| 6A980767-1DD2-11B2-99A6-080020736631 | ||
| 6A96237F-1DD2-11B2-99A6-080020736631 | ||
| 6A8D2AC7-1DD2-11B2-99A6-080020736631 | ||
| NetBSD[E][22] | Swap partition | 49F48D32-B10E-11DC-B99B-0019D1879648 |
| FFS partition | 49F48D5A-B10E-11DC-B99B-0019D1879648 | |
| LFS partition | 49F48D82-B10E-11DC-B99B-0019D1879648 | |
| RAID partition | 49F48DAA-B10E-11DC-B99B-0019D1879648 | |
| Concatenated partition | 2DB519C4-B10F-11DC-B99B-0019D1879648 | |
| Encrypted partition | 2DB519EC-B10F-11DC-B99B-0019D1879648 | |
| ChromeOS[23] | ChromeOS kernel | FE3A2A5D-4F32-41A7-B725-ACCC3285A309 |
| ChromeOS rootfs | 3CB8E202-3B7E-47DD-8A3C-7FF2A13CFCEC | |
| ChromeOS future use | 2E0A753D-9E48-43B0-8337-B15192CB1B5E | |
| Haiku[24] | Haiku BFS | 42465331-3BA3-10F1-802A-4861696B7521 |
| MidnightBSD[E][25] | Boot partition | 85D5E45E-237C-11E1-B4B3-E89A8F7FC3A7 |
| Data partition | 85D5E45A-237C-11E1-B4B3-E89A8F7FC3A7 | |
| Swap partition | 85D5E45B-237C-11E1-B4B3-E89A8F7FC3A7 | |
| Unix File System (UFS) partition | 0394EF8B-237E-11E1-B4B3-E89A8F7FC3A7 | |
| Vinum volume manager partition | 85D5E45C-237C-11E1-B4B3-E89A8F7FC3A7 | |
| ZFS partition | 85D5E45D-237C-11E1-B4B3-E89A8F7FC3A7 |
- A. ^ The GUIDs in this table are written assuming a little-endian byte order. For example, the GUID for an EFI System partition is written as {C12A7328-F81F-11D2-BA4B-00A0C93EC93B} here, which corresponds to the 16 byte sequence 28h 73h 2Ah C1h 1Fh F8h D2h 11h BAh 4Bh 00h A0h C9h 3Eh C9h 3Bh — only the first three blocks are byte-swapped.
- B. ^ The formation of this GUID does not follow the GUID definition; it is formed by using the ASCII codes for the string "Hah!IdontNeedEFI". Such formation of "GUID" value breaks down the guaranteed uniqueness of GUID.
- C. a b Previously Linux used the same GUID for the data partitions as Windows (Basic data partition: {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7}). Linux never had a separate unique partition type GUID defined for its data partitions. This created problems when dual-booting Linux and Windows in UEFI-GPT setup. The new GUID (Linux filesystem data: {0FC63DAF-8483-4772-8E79-3D69D8477DE4}) was defined jointly by GPT fdisk and GNU Parted developers. It is identified as type code 0x8300 in GPT fdisk. (See definitions in gdisk's parttypes.cc)
- D. a b The GUID for
/usron Solaris is used as a generic GUID for ZFS by Mac OS X. - E. a b NetBSD and MidnightBSD had used the FreeBSD GUIDs before their unique GUIDs were created.
