Show Table of Contents






附录 A. 磁盘分区简介
注意
本附录不一定适用于 AMD64 和 Intel 64 以外的架构。但在这里提及的一般原理可能适用。
本小节讨论了基本磁盘概念、磁盘重新分区策略、Linux 系统使用的命名方案以及其他相关话题。
如果您对磁盘分区没有意见,可以直接跳至 第 A.2 节 “磁盘重新分区策略” 查看有关释放磁盘空间准备 Red Hat Enterprise Linux 安装的详情。
A.1. 硬盘基本概念
硬盘有一个非常简单的功能 - 它们保存数据并使用命令搜索它们。
讨论类似磁盘分区的问题时,重要的是要了解底层硬件。但因为这个理论非常复杂且广泛,在这里只介绍几本概念。本附录使用一组磁盘驱动器简化图标帮助您理解分区的过程和理论。
图 A.1 “未使用过的磁盘驱动器”,显示全新未使用的磁盘驱动器。

图 A.1. 未使用过的磁盘驱动器
A.1.1. 文件系统
要在磁盘驱动器中保存数据,则首先需要格式化该磁盘驱动器。格式化(通常称“生成文件系统”)是向驱动器中写入信息,在未格式化驱动器中为空白空间建立顺序。

图 A.2. 有文件系统的磁盘驱动器
如 图 A.2 “有文件系统的磁盘驱动器” 所指,文件系统所指派的顺序涉及了一些折衷方案:
- 驱动器中的一小部分可用空间被用来存储与文件系统有关的数据,这可以被视作额外部分。
- 文件系统将剩余的空间分成小的一定大小的片段。在 Linux 中,这些片段就是块。[4]
注:这里没有单一、通用的文件系统。如 图 A.3 “含有不同文件系统的磁盘驱动器” 所示,不同的文件系统会彼此不兼容,也就是说,支持某一文件系统(或者相关的文件系统类型)的操作系统可能不支持另外一种文件系统。但比如 Red Hat Enterprise Linux 就支持很多文件系统(包括许多被其他操作系统使用的文件系统),这就使得在不同文件系统之间的数据交换变得容易了。

图 A.3. 含有不同文件系统的磁盘驱动器
在磁盘中写入文件系统只是第一步。这个进程的目的实际上是要保存和检索数据。下图显示了写入数据后的磁盘驱动器:

图 A.4. 已写入数据的磁盘驱动器
如 图 A.4 “已写入数据的磁盘驱动器” 所示,某些之前的空数据块现在也存放着数据。然而,只看这个框图,我们不能确认这个磁盘中有多少个文件系统。这有可能是一个,也有可能是多个,因为所有的文件都使用至少一个数据块,而有些文件则使用多个块。另外一个值得注意的地方是,已经被使用的块不一定组成连续的空间;未使用的和已使用的块可以散布排列。这被称作碎片。当尝试调整现存分区的大小时,碎片会对其产生影响。
和大多数与计算机相关的技术一样,与磁盘驱动器刚发明时相比,它已经有了很大的变化。特别是变得越来越大。不是物理大小变大,而是保存信息的容量增大。同时额外的容量让使用磁盘驱动器的方法发生了根本改变。
A.1.2. 分区:将一个驱动器变成多个
磁盘驱动器可分成分区。每个分区可作为独立磁盘访问。这可通过添加分区表完成。
将磁盘空间分配到独立磁盘分区有如下理由,例如:
- 将操作系统数据与用户数据进行合理分隔。
- 可使用不同的文件系统
- 可在一台机器中运行多个操作系统
目前有两个物理硬盘分区布局标准:主引导记录(MBR)和 GUID 分区表(GPT)。MBR 是基于 BIOS 的计算机使用的较老的磁盘分区方法。GPT 是较新的分区布局,它是统一可扩展固件界面(UEFI)的一部分。本小节主要论述主引导记录(MBR)磁盘分区方案。有关GUID 分区表(GPT)分区布局详情请查看 第 A.1.4 节 “GUID 分区表(GPT)”。
注意
虽然本章图表中所显示的分区表和实际磁盘驱动器是分开的,这并不完全正确。事实上,分区表是保存在磁盘的最开始,在任何文件系统或用户数据之前。但是为了清楚起见,我们在图表中将其分开。

图 A.5. 带有分区表的磁盘驱动器
如 图 A.5 “带有分区表的磁盘驱动器” 所示,分区表被分成 4 个部分或者说是 4 个主分区。主分区是硬盘中只包含一个逻辑分区(或部分)的分区。每个分区都存放着定义单一分区的必要的信息,这意味着分区表最多可以定义 4 个分区。
每个分区表条目包含几个分区的重要特性:
- 在磁盘上分区开始和结束的地点(起止点)
- 分区是否"活跃"
- 分区的类型
起点和终点实际上定义了分区的大小和在磁盘中的位置。"active" 标签用于某些操作系统的引导装载程序。换句话说就是引导该分区中标记为 "active" 操作系统。
这个类型是一个数字,可用来识别分区的预期用量。有些操作系统使用分区类型表示具体文件系统类型、为分区添加标签使其与特定操作系统关联、表示该分区中包含引导操作系统或者以上三者之和。
请在 图 A.6 “采用单一分区的磁盘驱动器” 查看采用单一分区的磁盘驱动器示例。

图 A.6. 采用单一分区的磁盘驱动器
这个示例中的单一分区是标记为
DOS。这个标签代表分区类型,DOS 是最常用的一个。下表为常用分区类型以及代表这些分区的十六进制数字列表。
表 A.1. 分区类型
| 分区类型 | 值 | 分区类型 | 值 |
|---|---|---|---|
| Empty | 00 | Novell Netware 386 | 65 |
| DOS 12-bit FAT | 01 | PIC/IX | 75 |
| XENIX root | 02 | Old MINIX | 80 |
| XENIX usr | 03 | Linux/MINUX | 81 |
| DOS 16-bit <=32M | 04 | Linux swap | 82 |
| Extended | 05 | Linux native | 83 |
| DOS 16-bit >=32 | 06 | Linux extended | 85 |
| OS/2 HPFS | 07 | Amoeba | 93 |
| AIX | 08 | Amoeba BBT | 94 |
| AIX bootable | 09 | BSD/386 | a5 |
| OS/2 Boot Manager | 0a | OpenBSD | a6 |
| Win95 FAT32 | 0b | NEXTSTEP | a7 |
| Win95 FAT32 (LBA) | 0c | BSDI fs | b7 |
| Win95 FAT16 (LBA) | 0e | BSDI swap | b8 |
| Win95 Extended (LBA) | 0f | Syrinx | c7 |
| Venix 80286 | 40 | CP/M | db |
| Novell | 51 | DOS access | e1 |
| PReP 引导 | 41 | DOS R/O | e3 |
| GNU HURD | 63 | DOS secondary | f2 |
| Novell Netware 286 | 64 | BBT | ff |
A.1.3. 分区中的分区 - 扩展分区概述
如果四个分区还不能满足您的需要,则可以使用扩展分区生成额外的分区。只要将分区类型设置为 "Extended" 即可。
扩展分区就象是其自身的磁盘驱动器 - 它本身就有分区表,该分区表可指向一个或者多个分区(现称之为逻辑分区,以示与四个主分区之不同),这些分区完全是在扩展分区中。如 图 A.7 “使用扩展分区的磁盘驱动器” 所示,一个磁盘驱动器中有一个主分区和一个扩展分区,该扩展分区中包含两个逻辑分区(以及一些未分区的剩余空间)。

图 A.7. 使用扩展分区的磁盘驱动器
如此图所示,主分区和逻辑分区间有所不同 - 主分区只有四个,但可有无限个逻辑分区存在。但是因为 Linux 中访问分区的方法,不应在单一磁盘驱动器中定义 12 个以上的逻辑分区。
A.1.4. GUID 分区表(GPT)
GUID 分区表(GPT)是一个基于全局唯一识别符(GUID)的较新的分区方案。开发 GPT 是为了解决 MBR 分区表的局限,特别是磁盘的最大可使用存储空间限制。MBR 无法处理超过 2.2TB 的存储空间,与之不同的是 GPT 能够处理超过此硬盘大小的硬盘,其最大可处理的磁盘大小为 2.2ZB。另外,默认情况下 GPT 最多支持生成 128 个主分区。如果为分区表分配更多的空间,这个数字还能增大。
GPT 磁盘使用逻辑块寻址(LBA)及如下分区布局:
- 要保留与 MBR 磁盘的向后兼容性,则需要将 GPT 的第一个扇区(LBA 0)留给 MBR 数据,我们称之为 “保护性 MBR(protective MBR)”。
- 主 GPT 标头从该设备的第二个逻辑块(LBA 1)开始。该标头包含磁盘 GUID、主分区表位置、辅 GPT 标头位置以及其自身和主分区表的 CRC32 checksum。它还指定该分区表中的分区条目数。
- 默认主 GPT 表包括 128 个分区条目,每个条目为 128 字节,其分区类型 GUID 以及唯一 GUID。
- 副 GPT 表与主GPT表完全一致,主要是作为备份表使用,在主分区表崩溃时用来恢复。
- 副 GPT 标头从位于该磁盘的最后一个逻辑块中,可用来在主标头崩溃时恢复 GPT 信息。该标头包含磁盘 GUID、主分区表位置、辅分区表以及主 GPT 标头位置、以及其自身和副分区表的 CRC32 checksum、以及可能的分区条目数。
重要
必须有 BIOS引导分区方可成功将引导装载程序安装到包含 GPT(GUID 分区表)的磁盘中。其中包括使用 Anaconda 初始化的磁盘。如果该磁盘已包含 BIOS 引导分区,则该磁盘将会重复使用。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.