1. 分区表基础：MBR与GPT分区表结构详解
分区表这东西，说白了就是硬盘的「目录索引」。你想想看，一块硬盘动辄几TB，操作系统怎么知道哪里存了你的照片、哪里装了游戏？全靠分区表来指引。
我刚开始做运维那会儿，有一次客户服务器突然起不来，折腾了半天才发现是分区表被写坏了。从那以后，我对分区表的结构就格外上心。今天咱们就把MBR和GPT这两兄弟彻底聊透。
1.1 MBR分区表：老当益壮的传统方案
MBR（Master Boot Record）诞生于1983年，跟IBM PC/AT一个年代。虽然老，但现在很多老旧系统、嵌入式设备还在用。
MBR的物理布局
MBR位于硬盘的0号扇区（LBA 0），总共512字节。这512字节分了三块：
| 偏移地址 | 大小 | 内容 |
|---|---|---|
| 0x000 - 0x1BD | 446字节 | 第一阶段引导代码（Boot Code） |
| 0x1BE - 0x1FD | 64字节 | 分区表（4个分区条目，每个16字节） |
| 0x1FE - 0x1FF | 2字节 | 魔数 0x55AA（有效标志） |
嗯，这里要注意——分区表只有64字节，每个分区条目16字节，所以最多只能记录4个主分区。如果你想分更多区，就得搞扩展分区和逻辑分区这套绕弯子的方案。
核心限制：MBR使用32位LBA地址，最大只能管理2TB的磁盘。超过2TB的部分，操作系统根本认不出来。
MBR分区条目的16字节结构
每个分区条目虽然只有16字节，但信息量不小：
| 偏移 | 长度 | 含义 |
|---|---|---|
| 0x00 | 1字节 | 引导标志（0x80 = 可引导，0x00 = 不可引导） |
| 0x01-0x03 | 3字节 | CHS起始地址（已过时，现代系统基本不用） |
| 0x04 | 1字节 | 分区类型（0x07 = NTFS，0x83 = Linux ext，0x0C = FAT32） |
| 0x05-0x07 | 3字节 | CHS结束地址 |
| 0x08-0x0B | 4字节 | LBA起始扇区号 |
| 0x0C-0x0F | 4字节 | 分区总扇区数 |
我在项目中遇到过一台老服务器，MBR的0x55AA标志被病毒改成了0x55BB，结果BIOS直接不认盘。修复时用十六进制编辑器改回0x55AA就活了——有时候问题就这么简单。
1.2 GPT分区表：现代系统的标配
GPT（GUID Partition Table）是UEFI时代的产物。它解决了MBR的几乎所有痛点。
GPT的核心优势
- 容量大：使用64位LBA，最大支持8ZB（泽字节），你想想看，这够用几辈子了
- 分区数量多：理论上最多128个分区（Windows限制），Linux下可以更多
- 冗余保护：硬盘头和尾各存一份分区表，坏了一份还有备份
- CRC校验：分区表头和数据都有校验，数据完整性有保障
GPT的磁盘布局
GPT的布局比MBR复杂一些，但逻辑更清晰：
| LBA地址 | 内容 |
|---|---|
| LBA 0 | 保护MBR（防止老工具误认） |
| LBA 1 | GPT分区表头（含CRC、分区条目起始位置等） |
| LBA 2-33 | 分区条目数组（每个条目128字节，共128个） |
| LBA 34之后 | 实际数据分区 |
| 最后33个LBA | 备份GPT分区表（冗余） |
避坑指南：我曾经遇到过一块4TB硬盘，用MBR分区后只认到2TB。客户说「我明明买了4TB，怎么只有一半？」——这就是典型的MBR 2TB限制。换成GPT后问题立刻解决。
GPT分区条目结构（128字节）
每个分区条目比MBR丰富得多：
| 偏移 | 长度 | 含义 |
|---|---|---|
| 0x00-0x0F | 16字节 | 分区类型GUID（如EFI系统分区为C12A7328-F81F-11D2-BA4B-00A0C93EC93B） |
| 0x10-0x1F | 16字节 | 唯一分区GUID（每个分区全球唯一） |
| 0x20-0x27 | 8字节 | 起始LBA |
| 0x28-0x2F | 8字节 | 结束LBA |
| 0x30-0x37 | 8字节 | 属性标志（如只读、隐藏等） |
| 0x38-0x4F | 72字节 | 分区名称（UTF-16LE编码，最多36个字符） |
1.3 MBR vs GPT：一张表说清楚
| 对比项 | MBR | GPT |
|---|---|---|
| 最大磁盘容量 | 2TB | 8ZB |
| 最大分区数 | 4个主分区（或3主+1扩展） | 128个（Windows）/ 无限制（Linux） |
| 冗余备份 | 无 | 头尾双备份 |
| 数据校验 | 无 | CRC32校验 |
| 引导方式 | BIOS + 主引导记录 | UEFI + ESP分区 |
| 兼容性 | 所有系统 | Win 7+ / Linux / macOS |
1.4 分区表在启动流程中的角色
分区表在启动过程中扮演的角色，我习惯用「接力棒」来比喻。每一棒都依赖前一棒传递的信息。
传统BIOS + MBR启动流程
- BIOS自检：硬件初始化，找到启动设备
- 读取MBR：BIOS将0号扇区的446字节引导代码加载到内存
- 执行引导代码：MBR代码扫描分区表，找到标记为0x80的活动分区
- 加载VBR：从活动分区的第一个扇区加载卷引导记录（Volume Boot Record）
- 启动操作系统：VBR加载操作系统内核文件
常见故障点：如果MBR的0x55AA标志损坏，BIOS会提示「Missing operating system」。如果活动分区标志丢失，会提示「Invalid partition table」。这两种情况我修复过不下20次。
UEFI + GPT启动流程
- UEFI固件初始化：直接读取GPT分区表头
- 查找ESP分区：找到类型为EFI System Partition（GUID: C12A7328-F81F-11D2-BA4B-00A0C93EC93B）的分区
- 加载引导文件：从ESP分区的 \EFI\BOOT\BOOTX64.EFI 加载引导程序
- 启动操作系统：引导程序直接加载操作系统内核
你发现没有？GPT启动少了一层MBR引导代码的环节，更直接也更安全。而且GPT的备份机制意味着——就算主分区表被破坏了，系统还能从备份恢复。
1.5 知识体系总览
下面这张图把MBR和GPT的核心结构、启动流程串起来了，建议你多看几遍：
我个人建议，新装机或者新部署服务器，一律用GPT。除非你有特殊原因必须兼容老旧的BIOS系统。MBR虽然还能用，但它的2TB限制和单点故障风险，在今天的生产环境中已经越来越吃力了。