前言
翻译自维基百科GUID Partition Table。
其实这篇文章维基百科上有相应的中文版本，但是一来有些地方看不太明白，二来内容相比英文已经老旧，因此自己翻译了一遍。实际翻译下来，发现这个英文版本部分内容也是欠推敲的。我的翻译并不好，有些内容还照搬了此文的中文版本，但是对了解GPT分区表来说，已经足够。
GUID分区表
在计算机硬件中，GUID分区表（GPT，GUID Partition Table）是使用全局唯一标识符（GUID， globally unique identifiers），描述物理硬盘分区表结构的一个标准。尽管它属于统一可延伸固件接口（UEFI，Unified Extensible Firmware Interface）标准（统一EFI论坛打算用它代替PC BIOS）的一部分，但也被用在某些BIOS系统上。这是由于使用32比特存储逻辑块地址和大小信息的MBR分区表具有局限性，对每扇区512字节的磁盘 来说，MBR分区表项最大容量为2TiB（241或~2.20x1012字节）。不过，一些磁 盘厂商（希捷和西数）看到了这个正在接近的限制并把他们大容量磁盘的扇区提高到4K，这就把MBR的实际限制提高到了16TiB。由于这个理 论上“正确”的解决方案，这一变化暂时降低了使用GPT的需求，并在市场上带来了“从BIOS启动大容量块设备时如何分区最合适”的疑惑。 GPT把64比特用于逻辑块地址，最大允许大小为264-1个扇区的分区。对于每扇区512字节的磁盘，这会是 9.4ZB（9.4x1021字节）或8ZiB-512字节（9,444,732,965,739,290,426,880字节或18,446,744,073,709,551,615(264−1)扇区×512(29)字节每扇区）。
截至2010年，当前的大部分操作系统都支持GPT。包括OS X和Microsoft Windows在内的一些操作系统，只支持在具有EFI固件的系统上从GPT分区启动。但当前的大部分Linux发行版（如Debian）在基于传统的 BIOS固件的系统上以及基于EFI的系统上都能从GPT分区启动。
历史
始于20世纪80年代，广泛使用的MBR分区方案，其局限性影响了对现代化硬件使用。因此，在20实际90年代后期，Intel开发了新的 分区表格式并最终成为UEFI的一部分。截至2010年，GPT构成了UEFI规范的一个子集。
特点
基于MBR的分区表方案在主引导记录（MBR，master boot record）（在BIOS系统中，它也包含了开始系统启动过程的代码）插入了（通常是）四个“主”分区的分区信息。在GPT中，磁盘的第一个扇区被保留 作为“保护性MBR”，这样可以支持从一个GPT磁盘启动基于BIOS的计算机，但引导程序和操作系统必须都能识别GPT。无论扇区大小是多 少，GPT头起始于设备的第二个逻辑块。
与现代的MBR类似，GPT使用逻辑块寻址（LBA，logical block addressing）代替历史上的柱面-磁头-扇区（CHS,cylinder-head-sector）寻址。保护性MBR包含在LBA 0，GPT头从LBA 1起始。GPT头包含一个指向分区表（或分区项阵列Partition Entry Array）的指针，通常是LBA 2。UEFI规范规定，无论扇区大小是多少，至少要给分区项阵列分配16,384字节。在一个扇区为512字节的磁盘上，如果分区项阵列的大小是 16,384字节，每个分区项128字节，那么磁盘上第一个可用的扇区是LBA 34。
硬盘厂商正在过渡到4,096字节扇区。截至2010年，第一个这样的设备呈现给操作系统的，仍然是512字节的物理扇区，因此，当磁盘的 （隐藏）内部4KiB扇区边界与许多操作系统和文件系统常见的4KiB逻辑块、簇以及虚拟内存页面不致时，会使得性能下降。当磁盘被迫执行两 个“读取-修改-写入”以满足一个排列糟糕的4KiB写入操作时，这会成为一个特殊问题。如果第一个分区紧随在GPT之后，由于下一个块是 LBA34，而下一个4KiB边界起始于LBA 40，这种糟糕的排列默认就会发生。
为了与Windows Vista之前的大多数操作系统，包括DOS、OS/2以及Windows，相兼容，MBR分区必须依据传统的CHS寻址方案起始于磁道边界，终结于柱面 边界。甚至对于模拟的CHS结构（反映在BIOS里和MBR分区表的CHS扇区项里）的分区或只通过LBA访问的分区也是如此。扩展分区同样 也起始于柱面边界。
这就使得使用LBA访问磁盘时，第一个主分区通常起始于LBA 63，并在基于MBR的磁盘上产生62扇区的空白。这一空白有时被称为“MBR空白”、“启动磁道”或“内嵌区域”。（在使用另类LBA/CHS转换方案 或另类扩展CHS映射的老式计算机上，使用LBA访问的小磁盘上，或在仅使用CHS访问的磁盘上，这一值可以更小。不过在普通的硬盘上，通常 不会小于LBA16。）
从Windows Vista开始，作为其新引入的1MiB分区排列策略的一部分，第一个分区通常起始于2,047个空白的扇区之后，即LBA 2,048。这样，大扇区糟糕的排列默认就不会发生了，但对在其之前的操作系统及磁盘工具的兼容存在严重的问题。
基于Intel处理器的Mac机上的磁盘，通常格式化为GPT，而不是苹果分区映射（APM，Apple Partition Map）。
GPT还提供了冗余特性，磁盘的起始和结尾处都储存有GPT头和分区表。
如果给分区表项阵列分配了最小的16,384字节，并且每个分区表项的都是128字节，可创建分区的最大数量为128。
上面是GPT分区方案磁盘布局的图示。在这一示例中，每一个逻辑块（LBA）大小是512字节，每一分区项长度128字节，相应地分区项位于LBA2-33。负数表示的LBA意味着它位于卷的尾部，-1是最后一个可访问的块。
传统MBR（LBA 0）
按惯例，在IBM PC兼容系统中，磁盘的第一个扇区保存着主引导记录（MBR，Master Boot Record）。MBR包含磁盘分区信息，以及引导程序的第一阶段引导代码（用在基于BIOS的系统中）。为了实现有限的兼容性，GPT仍然为MBR保留 了这一扇区，但它只是用来阻止基于MBR的磁盘工具识别错误，从而覆盖GPT磁盘。它被称为“保护性MBR”。
一个单独的分区，类型EEh，包含了整个GPT磁盘（“整个”实际是指在MBR能代表的磁盘的最大值），指出并识别其为GPT。不能读取 GPT磁盘的操作系统和工具会把认为磁盘包含一个未知类型分区，并且没有剩余空间，并拒绝修改磁盘（除非用户明确要求，并确认要删除此分 区）。这使得分区被破坏的可能性降到最低。另外，能识别GPT的操作系统会检查保护性MBR，如果它所包含分区的类型不是EEh，或者目标设 备上有多个分区，则不会对设备进行操作。
MBR布局（同样也是保护性MBR布局）是根据每扇区512字节定义的，大小是512字节。而实际的扇区大小在不同的媒体（例如MO磁盘， 或具有高级格式（Advanced Format）的硬盘上会更大。MBR中这额外的空间通常不会使用。
如果磁盘的实际大小超出了MBR分区表中传统32比特LBA项所能表示的最大值，这一分区大小的记录值会被修剪为此最大值，磁盘的剩余空间 会被忽略。假设磁盘每扇区大小是512字节，这一最大值是2TiB。对4KiB扇区的磁盘，其最大值是16TiB。由于许多较老的操作系统和 工具把扇区大小固化为512字节，或局限于32位运算，超出2TiB的限制会产生严重的兼容问题。
在支持通过BIOS而不是EFI引导GPT分区的操作系统中，第一扇区仍然用来存储引导程序第一阶段引导代码，但这代码修改为可以识别 GPT分区。位于MBR中这样的引导程序不能假定每扇区大小是固定的512字节。
苹果公司在Intel架构的Mac机上用Boot Camp软件创建混合分区表，来允许启动Windows（在开发Boot Camp时，Windows并不支持GPT或EFI）。在这种系统中，保护性分区被缩小，从扇区1到混合MBR第1个常规分区的前一个扇区。其它分区被定 义为与接下来的三个GPT分区相对应。
分区表头（LBA 1）
分区表头定义了磁盘上可使用的块（block），也定义了构成分区表的分区项的数量和大小。64位Windows Server 2003可以创建128个分区。它保留了128个分区项，每个长128字节。（EFI规范要求最少应为分区表保留16,384字节。因此，如果每个分区表 项使用最小值128字节，可容得下128个分区项。）
表头包含磁盘的全局唯一标识符（GUID，globally unique identifier）。它还记录了自己的大小和位置（通常是 LBA 1）还有第二GPT表头和分区表的大小和位置（通常在磁盘的最后一个扇区）。重要的是，它还包含了一个它自己和分区表的CRC32校 验和，可由固件、引导程序、操作系统在启动时进行校验。因此，不能用十六进制编辑器修改GPT的内容，因为改动会让校验和失效。在这种情况 下， 磁盘恢复软件可能会使用第二GPT覆盖主GPT。如果两个GPT都包含无效的校验和，磁盘会无法使用。
| 偏移 | 长度 | 内容 |
|---|---|---|
| +0 | 8 bytes | 签名("EFI PART", 45h 46h 49h 20h 50h 41h 52h 54h) |
| +8 | 4 bytes | 版本修订(从GPT版本1.0 \(至少到UEFI版本2.3.1\)，其值为00h 00h 01h 00h) |
| +12 | 4 bytes | 以little endian表 示的头大小(以字节为单位, 通常是5Ch 00h 00h 00h，表示92字节) |
| +16 | 4 bytes | 头的CRC32(从偏移+0到头结束)，计算时 这一区域被视为0 |
| +20 | 4 bytes | 保留; 必须是0 |
| +24 | 8 bytes | 当前LBA(本GPT头的位置) |
| +32 | 8 bytes | 备份LBA(其他GPT头的位置) |
| +40 | 8 bytes | 分区第一可用LBA(主分区表结尾的LBA + 1) |
| +48 | 8 bytes | 最后一个可用的LBA(第二分区表起始LBA - 1) |
| +56 | 16 bytes | 磁盘GUID(类UNIX系统中也会被称为UUID) |
| +72 | 8 bytes | 分区项阵列的LBA(在主GPT头中始终是2) |
| +80 | 4 bytes | 阵列中分区项的数量 |
| +84 | 4 bytes | 单个分区项的大小(通常是128) |
| +88 | 4 bytes | 分区阵列的CRC32 |
| +92 | * | 保留; 对块（block）剩下的空间来说，其值必须是0(对512字节扇区是420字节; 对大与512字节的扇区可以更大) |
| LBA大小 | 总计 | |
主GPT头当前和备份LBA的值应是磁盘的第二扇区（LBA 1）和最后一个扇区。磁盘尾部第二GPT头识别位于它前面的自己的分区表。
必须从LBA 1这个相对位置引用分区表，也就是说应该通过LBA 1访问。若错误地假设分区表紧跟在MBR（保存在LBA 0）的512字节之后，在每扇区4K的磁盘上，会让它成为LBA 0的一部分。我们所描述的排列碰巧位于扇区大小是512字节的磁盘上，如果磁盘扇区大于512字节，传统MBR和GPT头之间可能会有未使用的空白。若进 行了多扇区读操作，当引用这一表格时，实际扇区大小必须被包含在计算中。
分区项
| 偏移 | 长度 | 内容 |
|---|---|---|
| 0 | 16 bytes | 分区类型GUID |
| 16 | 16 bytes | 唯一的分区GUID |
| 32 | 8 bytes | 第一LBA (little endian) |
| 40 | 8 bytes | 末尾LBA (包括它本身, 通常是奇数(odd)) |
| 48 | 8 bytes | 属性标志(例如比特60表示只读) |
| 56 | 72 bytes | 分区名(36个UTF-16LE编码单元) |
| 共128字节 |
GPT使用简单直白的项目描述分区。头16字节是代表分区类型的GUID。例如，EFI系统分区的GUID是{C12A7328- F81F-11D2-BA4B-00A0C93EC93B}。接下来的16字节包含分区的唯一GUID。然后是64位的起始及结束LBA，分 区属性及分区名。因为GUID的自然属性和设计目的，不需要一个中心登记表来确保GUID分区类型标识符的唯一性。磁盘上分区项阵列的位置在 GPT头中定义。
GPT头包含一个区域指明了分区表项的大小。要求最小应是128字节，不过具体实现时必须允许其他字节（请看这一警 告）。
在计算时不能假设扇区是固定的512字节大小（请看Advanced Format），也就是说一个扇区可能可以容纳不止4个分 区项，还有可能（未来可能分区表项可能会更大）一个扇区只保存分区项的一部分。除头两个扇区（LBA 0和LBA 1）以外，GPT规范只是描述了数据结构的大小和组织方式，没有描述在存储时应占用磁盘上多少个扇区。
微软根据这一TechNet 文章进一步细分了属性标志：低4字节代表与分区类型无关的属性，高4字节取决于分区属性。微软通常用到下面这些位：
| 位 | 内容 |
|---|---|
| 0 | 系统分区(磁盘分区工具必须保持分区不变) |
| 2 | 传统BIOS可启动(等价于MBR分区表分 区项偏移+0h处的活动标志(通常在第7位设置))[6] |
| 60 | 只读 |
| 62 | 隐藏 |
| 63 | 不要自动挂载(也就是说不要分配盘符) |
支持GPT的操作系统
混合MBR不标准，并且不同操作系统可以不同方式对其进行解释。除非注明，操作系统遇到混合MBR时优先处理GPT分区表。
在这一架构和版本上无原生支持应被理解为：
- 不支持作为数据盘，操作系统只能识别在保护性MBR中找到的传统分区。可分离（detachable）磁盘：只支持MBR分区工具； 最终用户程序无法访问。GPT包含的原始数据可由第三方低级磁盘管理工具访问。真正的操作系统级读取或读取写入支持取决于第三方厂商的软 件。
UNIX和类UNIX操作系统
| 系统类别 | 版本 | 平台 | 读写支持 | 启动支持 | 注解 |
|---|---|---|---|---|---|
| FreeBSD | 从7.0开始 | IA-32, x64 | Yes | Yes | 在混合MBR中，GPT和MBR分区标识符可能都会用到。 |
| Linux | 绝大多数x86 Linux发行版Fedora 8+ 和 Ubuntu 8.04+[9] | IA-32, x64 | Yes | Yes | 一些工具不支持或只有有限支持。util-linux的fdisk可认出GPT分区但不能使用或修改它。[citation needed] GNU fdisk(至少是在1.2.5版以前)甚至不能认出GPT，并可能严重损坏GPT[citation needed]新工具如gdisk,[10] GNU Parted,[11][12] Syslinux, grub 0.96+patches和grub2已支持GPT。 |
| Mac OS X | 从10.4.0(一些特性从10.4.6)开始[13] | IA-32, x64 | Yes | Yes | 只有Intel Macintosh计算机能从GPT启动。 |
| MidnightBSD | 从0.4-CURRENT开始 | IA-32, x64 | Yes | 要 求 BIOS | 在混合MBR中，GPT和MBR分区标识符可能都会用到。 |
| Solaris | 从Solaris 10开始 | IA-32, x64, SPARC | Yes | Yes | [14] |
| HP-UX | 从HP-UX 11.20开始 | IA-64 | Yes | Yes | [15] |
Windows：32位版本
微软在32位平台不支持EFI，因此不允许从GPT分区启动。
| 操作系统版本 | 发布日期 | 平台 | 读或写支持 | 启动支持 | 注解 |
|---|---|---|---|---|---|
| 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中MBR具有高优先级[7] |
| Windows Vista | 2006-07-22 | IA-32 | Yes | No | 在混合MBR中MBR具有高优先级[7] |
| Windows Server 2008 | 2008-02-27 | IA-32 | Yes | No | 在混合MBR中MBR具有高优先级[7] |
| Windows 7 | 2009-10-22 | IA-32 | Yes | No | 在混合MBR中MBR具有高优先级[7] |
| Windows 8 | 2012-08-01 | IA-32 | Yes | No | 在混合MBR中MBR具有高优先级[7] |
Windows：64位版本
| 操作系统版本 | 发布日期 | 平台 | 读和写支持 | Boot support | Note |
|---|---|---|---|---|---|
| Windows XP Professional x64 Edition Windows Server 2003 |
2005-04-25[16] | x64 | Yes | No | 在混合MBR中MBR具有高优 先级[7] |
| Windows Server 2003 | 2005-04-25 | IA-64 | Yes | Yes | 在混合MBR中MBR具有高优先级[7] |
| Windows Vista | 2006-07-22 | x64 | Yes | 要 求UEFI | 在混合MBR中MBR具有高优先级[7] |
| Windows Server 2008 | 2008-02-27 | x64 | Yes | 要 求UEFI | 在混合MBR中MBR具有高优先级[7] |
| Windows Server 2008 | 2008-02-27 | IA-64 | Yes | Yes | 在混合MBR中MBR具有高优先级[7] |
| Windows 7 Windows Server 2008 R2 |
2009-10-22 | x64 | Yes | 要 求UEFI | 在混合MBR中MBR具有高优先级[7] |
| Windows Server 2008 R2 | 2009-10-22 | IA-64 | Yes | Yes | 在混合MBR中MBR具有高优先级[7] |
| Windows 8 Windows Server 2012 |
2012-08-01 | x64 | Yes | 要 求UEFI | 在混合MBR中MBR具有高优先级[7] |
分区类型GUID
| 相关操作系统 | 分区类型 | 全局唯一标识符(GUID)[A] |
|---|---|---|
| (None) | 未使用 | 00000000-0000-0000-0000-000000000000 |
| MBR分区方案 | 024DEE41-33E7-11D3-9D69-0008C781F39F | |
| EFI系统分区 | C12A7328-F81F-11D2-BA4B-00A0C93EC93B | |
| BIOS启动分区[B] | 21686148-6449-6E6F-744E-656564454649 | |
| Intel快闪(iFFS，Intel Fast Flash)分区(用于Intel 快速启动(Intel Rapid Start)技术)[17][18] | D3BFE2DE-3DAF-11DF-BA40-E3A556D89593 | |
| Windows | 微软保留分区(MSR，Microsoft Reserved Partition) | E3C9E316-0B5C-4DB8-817D-F92DF00215AE |
| 基本数据分区[C] | EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 | |
| 逻辑磁盘管理器(LDM，Logical Disk Manager)元数据分区 | 5808C8AA-7E8F-42E0-85D2-E1E90434CFB3 | |
| 逻辑磁盘管理器数据分区 | AF9B60A0-1431-4F62-BC68-3311714A69AD | |
| Windows 恢复环境 | DE94BBA4-06D1-4D40-A16A-BFD50179D6AC | |
| IBM通用并行文件系统(GPFS，General Parallel File System)分区 | 37AFFC90-EF7D-4E96-91C3-2D7AE055B174 | |
| HP-UX | 数据分区 | 75894C1E-3AEB-11D3-B7C1-7B03A0000000 |
| 服务分区 | E2A1E728-32E3-11D6-A682-7B03A0000000 | |
| Linux | Linux文件系统数据[C] | 0FC63DAF-8483-4772-8E79-3D69D8477DE4 |
| RAID分区 | A19D880F-05FC-4D3B-A006-743F0F84911E | |
| Swap分区 | 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F | |
| 逻辑卷管理器(LVM，Logical Volume Manager)分区 | E6D6D379-F507-44C2-A23C-238F2A3DF928 | |
| 保留 | 8DA63339-0007-60C0-C436-083AC8230908 | |
| FreeBSD | 启动分区 | 83BD6B9D-7F41-11DC-BE0B-001560B84F0F |
| 数据分区 | 516E7CB4-6ECF-11D6-8FF8-00022D09712B | |
| Swap分区 | 516E7CB5-6ECF-11D6-8FF8-00022D09712B | |
| Unix文件系统 (UFS，Unix File System)分区 | 516E7CB6-6ECF-11D6-8FF8-00022D09712B | |
| Vinum卷管理器分区 | 516E7CB8-6ECF-11D6-8FF8-00022D09712B | |
| ZFS分 区 | 516E7CBA-6ECF-11D6-8FF8-00022D09712B | |
| Mac OS X | 分 层文件系统+(HFS+，Hierarchical File System Plus)分区 | 48465300-0000-11AA-AA11-00306543ECAC |
| 苹果UFS | 55465300-0000-11AA-AA11-00306543ECAC | |
| ZFS[D] | 6A898CC3-1DD2-11B2-99A6-080020736631 | |
| 苹果RAID分区 | 52414944-0000-11AA-AA11-00306543ECAC | |
| 苹果RAID分区, 离线 | 52414944-5F4F-11AA-AA11-00306543ECAC | |
| 苹果启动分区 | 426F6F74-0000-11AA-AA11-00306543ECAC | |
| 苹果标签(lable) | 4C616265-6C00-11AA-AA11-00306543ECAC | |
| 苹果电视恢复分区 | 5265636F-7665-11AA-AA11-00306543ECAC | |
| 苹果核心存储(也就是Lion FileVault)分区 | 53746F72-6167-11AA-AA11-00306543ECAC | |
| Solaris | 启动分区 | 6A82CB45-1DD2-11B2-99A6-080020736631 |
| 根分区 | 6A85CF4D-1DD2-11B2-99A6-080020736631 | |
| Swap分区 | 6A87C46F-1DD2-11B2-99A6-080020736631 | |
| 备份分区 | 6A8B642B-1DD2-11B2-99A6-080020736631 | |
| /usr分区[D] | 6A898CC3-1DD2-11B2-99A6-080020736631 | |
| /var分区 | 6A8EF2E9-1DD2-11B2-99A6-080020736631 | |
| /home分区 | 6A90BA39-1DD2-11B2-99A6-080020736631 | |
| 备用扇区(alternate sector) | 6A9283A5-1DD2-11B2-99A6-080020736631 | |
| 保留分区 | 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][19] | Swap分区 | 49F48D32-B10E-11DC-B99B-0019D1879648 |
| FFS分区 | 49F48D5A-B10E-11DC-B99B-0019D1879648 | |
| LFS分区 | 49F48D82-B10E-11DC-B99B-0019D1879648 | |
| RAID分区 | 49F48DAA-B10E-11DC-B99B-0019D1879648 | |
| 串联(concatenated)分区 | 2DB519C4-B10F-11DC-B99B-0019D1879648 | |
| 加密分区 | 2DB519EC-B10F-11DC-B99B-0019D1879648 | |
| ChromeOS[20] | ChromeOS内核 | FE3A2A5D-4F32-41A7-B725-ACCC3285A309 |
| ChromeOS根文件系统(rootfs) | 3CB8E202-3B7E-47DD-8A3C-7FF2A13CFCEC | |
| ChromeOS保留未来使用 | 2E0A753D-9E48-43B0-8337-B15192CB1B5E | |
| Haiku[21] | Haiku BFS | 42465331-3BA3-10F1-802A-4861696B7521 |
| MidnightBSD[E][22] | 启动分区 | 85D5E45E-237C-11E1-B4B3-E89A8F7FC3A7 |
| 数据分区 | 85D5E45A-237C-11E1-B4B3-E89A8F7FC3A7 | |
| Swap分区 | 85D5E45B-237C-11E1-B4B3-E89A8F7FC3A7 | |
| Unix文件系统(UFS)分区 | 0394EF8B-237E-11E1-B4B3-E89A8F7FC3A7 | |
| Vinum卷管理器分区 | 85D5E45C-237C-11E1-B4B3-E89A8F7FC3A7 | |
| ZFS分 区 | 85D5E45D-237C-11E1-B4B3-E89A8F7FC3A7 |
- A. ^ 本表中的GUID是以little-endian字节顺序写的。例如, EFI系统分区的GUID这里写为{C12A7328-F81F-11D2-BA4B-00A0C93EC93B}, 与之相应的16个字节顺序是28h 73h 2Ah C1h 1Fh F8h D2h 11h BAh 4Bh 00h A0h C9h 3Eh C9h 3Bh — 只有前三块按字节交换了。
- B. ^ GUID的格式未遵循GUID定义; 它由字符串"Hah!IdontNeedEFI"的ASCII代 码组成。这样的"GUID"值已经破坏了GUID的唯一性。
- C. a b Linux起初使用和Windows数据分区相同的GUID(基本数据分区: {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7})。 Linux从未给它的数据分区定义过单独的分区类型GUID。 当从UEFI-GPT双启动Linux和Windows时会产生问题。新的GUID(Linux文件系统数据: {0FC63DAF-8483-4772-8E79-3D69D8477DE4}) 由GPT fdisk和GNU Parted的开发者一起定义。在GPT fdisk中使用代码0x8300来识别它。(请查看gdisk's parttypes.cc中的定义)
- D. a b Solaris中/usr的GUID被Mac OS X用ZFS的普通GUID。
- E. a b 在它们自己的唯一GUID创立之前，NetBSD和MidnightBSD使用了FreeBSD的GUID。
Visits: 1146