GPT与MBR的比较。为什么不选MBR?

我是一个Linux用户。我的笔记本上没有Windows。而且硬盘大小小于2TB。那么为什么我要使用GPT表呢?我不能用老式的MBR吗?
我将有两个根分区,两个主目录分区和一个交换空间。所以当一个分区不是主分区,而是扩展分区时,是否会有性能差异?

GPT不是一个特定于Windows的分区方法。尽管如此,它消除了使MBR与现代硬件兼容所需的一些笨拙操作。 - K7AAY
3个回答

GPT 有几个优点:

  • 支持大于2TiB的磁盘。
  • 支持大于2TiB的分区。
  • 支持超过四个分区,无需区分主分区、扩展分区和逻辑分区。
  • 使用GUID作为类型代码,这意味着冲突/重复代码的风险较小。
  • 仅使用LBA寻址,而MBR同时使用LBA和CHS。(即使在MBR上,对于大约8GB以上的磁盘,CHS是无用的,因此在现代硬盘上几乎没有真正的冲突风险,它们比这要大得多。)
  • 在磁盘开头和结尾提供了重复的分区表结构,这使得从某些用户错误、错误和磁盘损坏中恢复可能。
  • 提供了重要数据结构的校验和,可以检测某些类型的分区表损坏。
  • 提供UTF分区描述字段,因此您可以为分区命名。请注意,这与分区中包含的文件系统的名称无关。
  • 被EFI/UEFI固件原生使用。
请注意 tebibyte(TiB;1024^4 字节)和 terabyte(TB;1000^4 字节)之间的区别。前者是IEEE-1541单位,而后者是SI单位。对于大多数磁盘测量来说,IEEE-1541单位更自然。一些文档和软件(尤其是较旧的内容)错误地将SI后缀应用到IEEE-1541测量中,这会造成困惑。
对于大多数安装来说,这些优势大部分都是次要的。最重要的两个优点是 GPT 是 EFI 的自然分区方案,以及没有主/扩展/逻辑的区分。其他 GPT 优势的综合效果值得注意,但对于大多数人来说并不是压倒性的问题。
自2011年中期以来,大多数引入的计算机,包括绝大部分搭载Windows 8及更高版本的系统,都使用EFI固件。如果您在EFI模式下启动这样一台计算机(而不是使用CSM,它可以启用BIOS模式引导),使用GPT分区表是默认选择。如果您在EFI模式下启动(或双启动)Windows,使用GPT是必需的(这是Windows的限制)。据我所知,Ubuntu也无法在EFI模式下安装到MBR磁盘,但您可能可以转换分区表类型,并在安装后成功引导。然而,在EFI模式下从MBR磁盘引导的测试不充分,可能在某些EFI上失败。
MBR的主/扩展/逻辑区分是在1980年代创建的一个笨拙的技巧,用于绕过MBR的四个分区限制。GPT默认支持128个分区,但如果绝对需要,这个限制可以提高。MBR逻辑分区访问速度与主分区相同,但由于它们依赖于跨越整个磁盘的多个扇区的链表数据结构,它们更容易受到损坏的影响。最大的问题只是处理像耗尽主分区或处理涉及主分区和逻辑分区的分区调整操作这样的麻烦事情(因此还需要调整扩展分区的大小,这是额外的操作--也是出错的额外机会)。
如果您在BIOS模式下使用小于2TiB的磁盘启动,最好还是坚持使用MBR,因为有些BIOS对从GPT磁盘启动反应不佳。这些问题通常可以解决,但最好一开始就避免遇到这些问题。在基于BIOS的计算机上使用GPT也会阻止您在该系统上安装Windows。不过,如果您知道自己在做什么并且想要使用GPT,在Ubuntu安装中以BIOS模式使用GPT是可行的,我不会劝阻您这样做 - 但如果遇到问题,您可能需要进行故障排除。
大多数现代计算机都使用EFI,因此,如果您以EFI模式启动,GPT可能是半必需的。如果您在这样的计算机上使用BIOS/CSM/legacy模式,则仍然更倾向于使用MBR,原因如前所述。就我个人而言,在这一点上,如果您有选择的话,我的建议是禁用 BIOS/CSM/legacy支持,并且在基于EFI的计算机上专门使用EFI模式。这简化了引导路径,并且减少了出现问题的可能性。问题在于,有很多错误的建议,相反地造成了比解决问题更多的问题,据我估计。(例如,在本网站上搜索会发现许多由交叉模式操作系统安装和其他与在基于EFI的计算机上使用BIOS/CSM/legacy模式相关的问题。)
如果您有一个超过2TiB的磁盘,基本上必须使用GPT。唯一的例外是如果该磁盘使用4096字节的逻辑扇区大小,这将将2TiB MBR限制提高到16TiB。一些外部磁盘会这样做,我也听说过一些高端内部磁盘也会这样做。(请注意,许多磁盘具有4096字节的物理扇区和512字节的逻辑扇区。它们与具有512字节物理和逻辑扇区的磁盘具有相同的2TiB MBR限制。)

1那解释得很清楚。就我个人而言,我的笔记本是索尼VAIO,没有原装Windows的EFI引导让我头疼不已。我无法让机器从新安装的固态硬盘加载grub,只能从USB加载grub,然后手动从那里启动Ubuntu。所以我简单地重新分区为MBR样式表,现在一切都运行良好。 - daltonfury42
太棒了!在我的情况下,我遇到了一些问题,无法从一个MBR分区的U盘上启动,该U盘上安装了完整的Lubuntu系统(不是Live USB),这个U盘是用我妻子的2008年左右的Macbook白色机器制作的。我认为它期望使用EFI引导,所以我在Macbook上安装了rEFInd,虽然它能够识别到我的Lubuntu磁盘(U盘),但当我从rEFInd引导菜单中选择它时,却出现了“无可引导设备”的错误。我唯一能想到的是,如果我重新将Lubuntu安装到我的便携式U盘上,并使用GPT分区,也许它就能在我妻子的Macbook上正常工作,所以我现在打算尝试这样做。祝我好运! - Gabriel Staples
很有可能rEFInd正在尝试以BIOS/CSM/legacy模式引导USB驱动器,这在Mac上的外部磁盘上有点不稳定 - 有时可以工作,有时不能。这假设磁盘上甚至有一个支持BIOS模式的引导加载程序,但实际情况可能并非如此。使用rEFInd,直接以EFI模式引导Linux内核通常更好;然而,这需要正确的EFI文件系统驱动程序。这还假设EFI和内核具有相同的位深度。在这样一台旧的Mac上,可能并非如此。 - Rod Smith
小补充。我不知道为什么,但是在500GB硬盘上创建一个大的GPT分区比MBR分区多出一点可用空间。差别微乎其微(少于1MB),但是GPT更有优势。 - mmv-ru
mmv-ru,这很可能是分区工具的一个副产品。MBR在磁盘上占用了精确的一个扇区。理论上,你可以将除了这一个扇区之外的所有空间分配给一个分区(或最多四个分区)。相比之下,GPT占用了67个扇区(假设每个扇区为512字节,并且使用默认的分区表大小),因此在GPT下的理论最大可分配空间比MBR少66个扇区。当然,实际上分区工具所做的又是另一回事了。我猜测你所看到的情况可能是由于一个MBR工具在磁盘末尾留下了一个间隙。 - Rod Smith

对你来说,这没有任何区别。GPT的优点包括:

  • 大分区,超过2 TB
  • 无限数量的主分区

在你的情况下,你不需要第一个。通过创建扩展分区并在其中创建逻辑分区,可以实现第二个。

对于Linux来说,安装到逻辑分区或主分区都没有影响。但是使用GPT时,如果需要移动分区,可能会更方便一些,因为它们都是主分区。

性能上没有任何差异。

GPT的所有其他“优点”都非常微小,不值得一提。


3我喜欢备份分区表,因为我的新驱动器可能会插入新的UEFI系统,所以我只使用了GPT,并在它们所有的驱动器上都包含了efi和bios_grub分区。我甚至使用GPT来为更大的闪存驱动器分区。但正如Pilot6所说,没有太大的优势。我没有注意到任何使用GPT分区驱动器方面的问题或差异。https://wiki.archlinux.org/index.php/GUID_Partition_Table#Advantages_of_GPT - oldfred
请您详细说明一下您提到的“已包含efi和bios_grub分区”的陈述好吗?我很熟悉如何使用gparted,但是如何创建一个efi分区以及在其中放置什么内容,我不太了解。关于efi分区,我一无所知。另外,我曾经安装过大约6到8次Linux,但从未为安装创建超过3个分区:交换分区、windows_share分区以及用于Linux操作系统的主要ext4分区。 - Gabriel Staples

我已经思考了好几个月。以下是关于你问题的Windows答案:在我看来,GPT似乎要快得多。尽管我找不到任何支持下面所述的测试结果,但我发现很多猜测说除了启动时几乎没有性能差异外,其他方面都可以忽略不计。现在我对此并不那么确定。以下是我的观点:
我有一个2TB的三星D3 USB 3.0外置硬盘。我将它分成两个大约1TB的MBR分区。我的电脑是Windows 10 64位,华硕Z97-P主板,8GB内存,i5 4460 CPU。我在它格式化为MBR时运行了三次CrystalDiskMark x64测试,并得到以下结果:
MBR平均结果(所有MB/s): - 顺序读取Q32T1 40 - 4K Q32T1读取 1.47 - 顺序读取 142 - 4K读取 1.22 - 顺序写入Q32T1 101 - 4K Q32T1写入 8.7 - 顺序写入 112 - 4K写入 8.5
有着可悲的大量空闲时间,我备份了数据(约750GB),重新格式化为GPT,这次作为一个单独的2TB分区,将数据复制回硬盘,并再次运行了测试:
GPT平均结果(所有MB/s): - 顺序读取 Q32T1 165 - 4K读取 Q32T1 1.83 - 顺序读取 170 - 4K读取 1.5 - 顺序写入 Q32T1 135 - 4K写入 Q32T1 8.7 - 顺序写入 138 - 4K写入 8.6
所以,使用GPT时,顺序读取 Q32T1 的结果要高得多,而其他所有结果都比GPT更高,尽管不一定总是显著。
就这些差异的实际日常意义而言,我当然不是专家,但现在我倾向于在我认为可以使用GPT的情况下使用它(即避免无法读取GPT的旧操作系统)。

3我怀疑这个差异不是由于MBR->GPT的改变引起的。MBR测试结果非常接近通过USB 2连接的驱动器的40MB/s限制,这让人感到可疑。三星D3是USB 3.0接口的,我怀疑你在MBR测试中回退到了USB 2.0(你使用了同一个端口吗?)。 - 0xF2
是的,我使用了同一个端口,驱动器一直连接着(USB 3.0 主板集成接口)。 - JumpingJumping
7分区表无法以任何方式提高速度。你的测试中有些问题。 - Pilot6
8GPT和MBR数据结构都非常简单,它们之间可能引起的性能差异应该是微乎其微的。因此,要么你发现了一个极为尴尬的错误,要么你的测试方法有问题。我注意到你创建了不同大小的分区,这可能会产生重大影响。如果你进行了文件级别的备份和恢复,那么文件所在位置和碎片化程度都会发生变化,这可能会影响结果。换句话说,你有多个变量,因此无法确定哪一个导致了你所看到的结果。 - Rod Smith
2奇怪的是,分区表是由操作系统记住的(存储在内存中),一旦它们被加载。文件的写入速度受到文件系统类型和文件的性质(少量大文件或数百万个小文件)的影响。MBR / GPT之间的差异可能只是微小的(毫秒级或更短)延迟,在加载分区表时会发生...而且,这个表不会重新加载,直到磁盘被拔掉或者通过某个应用程序请求改变分区结构。 - kravemir