3、GPT分区表详解：GPT头部结构、分区条目解析、CRC校验机制、备份分区表的重要性

说到GPT分区表，我得先坦白一件事。早年我做嵌入式Linux开发时，一直用MBR，觉得够用了。直到有一次给一个64位ARM设备做系统移植，硬盘容量超过2TB，MBR直接罢工。嗯，从那以后，GPT就成了我的标配。

GPT全称是GUID Partition Table，说白了就是全局唯一标识分区表。它比MBR强在哪？我总结三点：支持超大容量、分区数量几乎不限、自带冗余备份。今天咱们就把它的底裤扒干净。

3.1 GPT头部结构：分区表的“总指挥”

GPT头部位于磁盘的LBA 1（逻辑块地址1），紧跟在保护MBR之后。它就像一本分区表的目录，告诉你分区条目在哪、有多少个、校验值是多少。

我习惯把GPT头部看作一个结构体，每个字段都有明确含义。下面这张图能帮你快速建立整体认知：

GPT头部具体长什么样？我直接给你看它的结构定义：

typedef struct {
    uint64_t  signature;          // 签名，固定为"EFI PART"
    uint32_t  revision;           // 版本号，当前为1.0
    uint32_t  header_size;        // 头部大小，通常为92字节
    uint32_t  header_crc32;       // 头部CRC32校验值
    uint32_t  reserved;           // 保留，必须为0
    uint64_t  my_lba;             // 当前头部所在LBA
    uint64_t  alternate_lba;      // 备份头部所在LBA
    uint64_t  first_usable_lba;   // 第一个可用LBA
    uint64_t  last_usable_lba;    // 最后一个可用LBA
    uint8_t   disk_guid[16];      // 磁盘唯一GUID
    uint64_t  partition_entry_lba; // 分区条目起始LBA
    uint32_t  num_partition_entries; // 分区条目数量
    uint32_t  partition_entry_size;  // 每个条目大小（128字节）
    uint32_t  partition_entry_array_crc32; // 分区条目数组CRC32
} gpt_header_t;

关键字段解读：

signature：固定为0x5452415020494645，即ASCII的"EFI PART"。我见过有人手写GPT时把这个写错，结果系统死活不认盘。
my_lba 和 alternate_lba：这两个字段指向主备头部的位置。备份头部在磁盘最后一个LBA。
partition_entry_array_crc32：分区条目数组的校验值。这个很重要，后面细说。

3.2 分区条目解析：每个分区都有“身份证”

分区条目从LBA 2开始，每个条目固定128字节。你想想看，128字节描述一个分区，信息量相当大。我拆开给你看：

typedef struct {
    uint8_t   partition_type_guid[16];  // 分区类型GUID
    uint8_t   unique_partition_guid[16]; // 分区唯一GUID
    uint64_t  starting_lba;              // 起始LBA
    uint64_t  ending_lba;                // 结束LBA
    uint64_t  attributes;                // 属性标志
    uint16_t  partition_name[36];        // 分区名称（UTF-16LE）
} gpt_entry_t;

这里我重点说几个坑：

分区类型GUID：不是随便写的。EFI系统分区有固定GUID（C12A7328-F81F-11D2-BA4B-00A0C93EC93B），微软的MSR分区又是另一个。我见过有人把类型写错，导致Windows安装程序不认盘。
起始和结束LBA：注意是包含关系。结束LBA是分区最后一个扇区，不是长度。计算分区大小时要加1。
分区名称：用UTF-16LE编码，最多36个字符。中文分区名在这里是支持的，但很多烧录工具没处理好编码，会显示乱码。

我的习惯：在烧录工具中解析分区条目时，我会先校验partition_entry_array_crc32。如果校验失败，直接报错，不继续往下读。这样可以避免读到损坏的分区表导致误写。

3.3 CRC校验机制：数据完整性的“守门员”

GPT用了两层CRC32校验，这是它比MBR高明的地方。MBR几乎没有校验，扇区坏了就是坏了。

第一层：头部CRC32

计算范围是GPT头部除signature和header_crc32字段外的所有字节。计算前要把header_crc32字段置0。我写代码时经常忘记置0，算出来的值永远不对。

第二层：分区条目数组CRC32

计算范围是整个分区条目数组（默认128个条目，共16KB）。这个值存在GPT头部的partition_entry_array_crc32字段中。

校验流程是这样的：

读取GPT头部，先校验header_crc32。如果不对，尝试用备份头部。
头部校验通过后，读取分区条目数组，校验partition_entry_array_crc32。
两层都通过，才认为分区表是完整的。

我曾经踩过的坑：有一次设备频繁掉电，分区条目数组损坏了，但头部CRC32还是好的。如果只校验头部，就会读到一堆乱码分区。后来我强制要求工具必须做双层校验，缺一不可。

3.4 备份分区表：关键时刻的“救命稻草”

GPT的备份机制很简单：在磁盘末尾，把主GPT头部和分区条目数组各复制一份。具体位置：

备份分区条目：从磁盘倒数第33个LBA开始，到倒数第2个LBA结束。
备份GPT头部：磁盘最后一个LBA（LBA -1）。

为什么备份这么重要？我给你说个真实案例：

有次我帮客户恢复一块2TB的硬盘，主GPT头部所在的LBA 1出现了坏道。Windows直接提示“磁盘未初始化”。客户差点以为数据全没了。我手动读取备份GPT头部，发现完好无损。把备份头部写到LBA 1，分区全部回来了，数据一个没丢。

从那以后，我设计的烧录工具都强制做以下检查：

检查项	主GPT	备份GPT	处理策略
头部CRC32	通过	通过	正常使用主GPT
头部CRC32	失败	通过	用备份GPT恢复主GPT
头部CRC32	通过	失败	用主GPT恢复备份GPT
头部CRC32	失败	失败	报错，提示磁盘损坏

重要提醒：备份GPT不是摆设。我建议每次修改分区表后，都主动同步更新备份。很多工具只写主GPT，忘了写备份，一旦主GPT出问题，连恢复的机会都没有。

3.5 实战：如何用代码校验GPT完整性

最后，我分享一段实际项目中用的校验代码片段。这段代码我用了好几年，没出过问题：

// 校验GPT头部CRC32
int verify_gpt_header(gpt_header_t *header) {
    uint32_t saved_crc = header->header_crc32;
    header->header_crc32 = 0;  // 计算前必须置0
    
    uint32_t calc_crc = crc32((uint8_t*)header, header->header_size);
    header->header_crc32 = saved_crc;  // 恢复原值
    
    return (calc_crc == saved_crc) ? 0 : -1;
}

// 校验分区条目数组CRC32
int verify_gpt_entries(gpt_header_t *header, uint8_t *entries) {
    uint32_t calc_crc = crc32(entries, 
        header->num_partition_entries * header->partition_entry_size);
    
    return (calc_crc == header->partition_entry_array_crc32) ? 0 : -1;
}

// 完整校验流程
int verify_gpt(int fd) {
    gpt_header_t header;
    uint8_t entries[16384];  // 128 * 128 = 16KB
    
    // 1. 读取主GPT头部
    lseek(fd, 512, SEEK_SET);  // LBA 1
    read(fd, &header, sizeof(header));
    
    // 2. 校验头部
    if (verify_gpt_header(&header) != 0) {
        // 尝试读取备份头部
        // ... 备份恢复逻辑
        return -1;
    }
    
    // 3. 读取分区条目
    lseek(fd, header.partition_entry_lba * 512, SEEK_SET);
    read(fd, entries, sizeof(entries));
    
    // 4. 校验条目数组
    if (verify_gpt_entries(&header, entries) != 0) {
        // 分区条目损坏，尝试从备份恢复
        return -1;
    }
    
    return 0;  // 校验通过
}

这段代码看起来简单，但实际项目中要考虑的细节很多。比如读取备份头部时，要计算磁盘总大小，找到最后一个LBA。还有，如果磁盘是4K扇区，LBA大小是4096字节，不是512。这些边界情况，我在项目里都吃过亏。

📚 课程目录

3、GPT分区表详解：GPT头部结构、分区条目解析、CRC校验机制、备份分区表的重要性

3.1 GPT头部结构：分区表的“总指挥”

3.2 分区条目解析：每个分区都有“身份证”

3.3 CRC校验机制：数据完整性的“守门员”

3.4 备份分区表：关键时刻的“救命稻草”

3.5 实战：如何用代码校验GPT完整性