GPT分区表

前言

翻译自维基百科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。

GUID_Partition_Table_Scheme

上面是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都包含无效的校验和,磁盘会无法使用。

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头之间可能会有未使用的空白。若进 行了多扇区读操作,当引用这一表格时,实际扇区大小必须被包含在计算中。

分区项

GUID分区项格式
偏移 长度 内容
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操作系统

UNIX和类Unix操作系统GPT支持细节
系统类别 版本 平台 读写支持 启动支持 注解
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+patchesgrub2已支持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分区启动。

32位Microsoft Windows GPT支持细节[8]
操作系统版本 发布日期 平台 读或写支持 启动支持 注解
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位版本

64位Microsoft Windows GPT支持细节[8]
操作系统版本 发布日期 平台 读和写支持 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。

点击量:136

发表评论

电子邮件地址不会被公开。 必填项已用*标注

3 + 3 =