48

I am a Linux user. I don't have Windows on my laptop. Also the hard drive size is less than 2 TB. Then why should I use GPT tables? Can't I go with old fasioned MBR?

I will be having two root partitions, two home partitions, and a swap space. So when a partition is not primary, but is extended, does that make any performance difference?

Improve this question
1
  • GPT is not a Windows=specific partitioning method. It removes some of the kludge required by making MBR work with modern hardware, though.
    – K7AAY
    May 10, 2018 at 18:51

3 Answers 3

Reset to default
61

There are several advantages to GPT:

  • Supports disks larger than 2TiB.
  • Supports partitions larger than 2TiB.
  • Supports more than four partitions, with no distinction between primary, extended, and logical partitions.
  • Uses GUIDs as type codes, which means there's less risk of conflicting/duplicate codes.
  • Uses LBA addressing exclusively, compared to MBR's dual use of LBA and CHS. (Even on MBR, CHS is useless on disks over about 8GB, though, so there's little risk of real conflict on modern hard disks, which are much bigger than this.)
  • Provides duplicate partition table structures at the start and end of the disk, which makes recovery from some types of user errors, bugs, and disk damage possible.
  • Provides checksums of important data structures, which enables detection of some types of partition table damage.
  • Provides a UTF partition description field, so you can give your partitions names. Note that this is independent of the name of the filesystem contained in the partition.
  • Is used natively by EFI/UEFI firmware.

Note the difference between a tebibyte (TiB; 1024^4 bytes) and a terabyte (TB; 1000^4 bytes). The former are IEEE-1541 units, whereas the latter are SI units. For most disk measurements, IEEE-1541 units are more natural. Some documentation and software (especially older stuff) mis-applies SI suffixes to IEEE-1541 measurements, which is confusing.

Most of these advantages are minor ones for most installations. The two most important advantages are the fact that GPT is the natural partitioning scheme for EFI and the lack of primary/extended/logical distinction. The other GPT advantages combined are worth noting, but are not overwhelming issues for most people.

Most computers introduced since mid-2011, including the vast majority of systems that shipped with Windows 8 and later, use EFI firmware. If you boot such a computer in EFI mode (rather than using the CSM, which enables BIOS-mode booting), using GPT is something of a default. If you boot (or dual-boot) Windows in EFI mode, using GPT is required (it's a Windows limitation). IIRC, Ubuntu won't install to an MBR disk in EFI mode, either, but you could probably convert partition table type and get it to boot after installing it. Booting from an MBR disk in EFI mode is poorly tested, though, and might fail on some EFIs.

The primary/extended/logical distinction of MBR is an awkward hack that was created in the 1980s to get around the four-partition limit of MBR. GPT defaults to supporting 128 partitions, but that limit can be raised if it's absolutely required. MBR logical partitions are no slower to access than primary partitions, but they are more prone to damage because of the fact that they rely on a linked-list data structure that spans multiple sectors scattered throughout the disk. The biggest problem is simply dealing with hassles like running out of primary partitions or handling partition resize operations that involve both primary and logical partitions (and that therefore also requires resizing an extended partition, which is an extra operation -- and an extra chance for something to go wrong).

If you're booting in BIOS mode on a sub-2TiB disk, it's probably best to stick with MBR, simply because there are some BIOSes that don't react well to booting from GPT disks. Such problems can usually be worked around, but it's easier not to run into the problems in the first place. Using GPT on a BIOS-based computer will also prevent you from installing Windows on that system. If you know what you're doing and want to use GPT, though, using GPT in BIOS mode for an Ubuntu installation is do-able, and I won't discourage you from doing so -- but if you run into problems you may need to troubleshoot it.

As most modern computers use EFI, though, GPT may be semi-required -- if you boot in EFI mode. If you use BIOS/CSM/legacy mode on such a computer, sticking to MBR is still preferable, for the reasons just noted. FWIW, my recommendation at this point, if you've got the choice, is to disable BIOS/CSM/legacy support and use EFI mode exclusively on EFI-based computers. This simplifies the boot path and makes it less likely that you'll run into problems. The trouble is that there's a lot of bad advice out there to do the contrary, which creates more problems than it solves, in my estimation. (A search on this site, for instance, reveals numerous problems caused by cross-mode OS installations and other issues related to using BIOS/CSM/legacy mode on an EFI-based computer.)

If you've got an over-2TiB disk, you pretty much must use GPT. The main exception to this is if the disk uses a 4096-byte logical sector size, which raises the 2TiB MBR limit to 16TiB. Some external disks do this, and I've heard of some high-end internal disks that do it, too. (Note that many disks have 4096-byte physical sectors and 512-byte logical sectors. They have the same 2TiB MBR limit as disks with 512-byte physical and logical sectors.)

Improve this answer
5
  • 1
    That was well explained. In my case, my laptop is a Sony vaio, and efi booting without OEM windows was a nightmare. I couldn't get the machine to load grub from the new ssd I installed and had to load grub from a USB to then manually boot Ubuntu from there. So I simply repartitioned to MBR style tables, and everything is working well for me.
    – daltonfury42
    May 29, 2015 at 15:04
  • Great info! In my case, I'm having trouble booting onto an MBR-partitioned thumb drive that has a full Lubuntu install (NOT Live USB) on it, when using my wife's old ~2008 Macbook white. I think it's expecting an EFI boot, so I installed rEFInd on the Macbook, and though it sees my Lubuntu disk (thumb drive), I'm getting the "no bootable device" error when I select it from the rEFInd boot menu. All I can think is that if I reinstall Lubuntu onto my portable thumb drive with a GPT partition on it instead, maybe it'll work on my wife's Macbook, so that's what I'm going to try now. Wish me luck!
    – Gabriel Staples
    May 28, 2016 at 19:51
  • Chances are rEFInd is trying to boot the USB drive in BIOS/CSM/legacy mode, which is a bit dodgy from external disks on Macs -- sometimes it works, sometimes it doesn't. This assumes there's even a BIOS-mode boot loader on the disk, which might not be the case. With rEFInd, it's usually better to boot a Linux kernel directly in EFI mode; however, this requires the right EFI filesystem driver. It also assumes that the EFI and kernel are of the same bit depth. On such an old Mac, that might not be the case.
    – Rod Smith
    May 29, 2016 at 14:19
  • Small addition. I not understand how, but make one big GPT partition on 500 Gb HDD give a little larger usable space in compare to MBR. The difference is negligible small (less that 1 Mb), but it is in favor of GPT.
    – mmv-ru
    Oct 31, 2016 at 14:55
  • mmv-ru, that's most likely an artifact of the partitioning tool(s) used. MBR consumes precisely one sector on the disk. In theory, you could allocate all but that one sector to a single partition (or up to four partitions). GPT, by contrast, consumes 67 sectors (assuming 512-byte sectors and the default partition table size), so the theoretical maximum allocatable space under GPT is 66 sectors less than under MBR. What partitioning tools actually do is another matter, of course. My guess is that what you're seeing is caused by an MBR tool that's leaving a gap at the end of the disk.
    – Rod Smith
    Oct 31, 2016 at 17:45
29

It will make no difference for you at all. Advantages of GPT are:

  • Large partitions, more that 2 TB
  • Unlimited number of primary partitions

In your case you do not need first. Second can be achieved by creating an extended partition and creating logical ones there.

For linux it does not matter to which type of partitions install (logical or primary). But with GPT it may be slightly more handy to move partitions if needed, because they will all be primary.

There is no performance difference at all.

All other "advantages" of GPT are so minor, that it is not worth to mention.

Improve this answer
2
  • 3
    I like having backup partition table, and since my newer drives might get plugged into a newer UEFI system, I have only used gpt and included both an efi & bios_grub partition on all of them. I even use gpt for larger flash drives. But as Pilot6 says no huge advantages. Have not notices any issues or differences with my gpt partitioned drives. wiki.archlinux.org/index.php/…
    – oldfred
    May 28, 2015 at 19:21
  • Can you expound upon your statement that you have "included both an efi and bios_grub partition" please? I know how to use gparted well, but how do you make an efi partition, and what do you put in it? I don't understand anything about efi partitions. PS. I've installed Linux ~6 or 8 times and never made more than 3 partitions for an install: swap, windows_share, and the main ext4 partition for the Linux OS.
    – Gabriel Staples
    May 28, 2016 at 19:36
2

I've been wondering about this for months. Here's a Windows answer to your question: GPT appears to me to be significantly faster. I've not found any test results to date that support what I have below, though I've found many guesses that the performance difference is negligible other than at startup. I'm not so sure now. Here's my tuppence worth:

I have a 2TB Samsung D3 USB 3.0 external drive. I had it split into two MBR partitions approx 1TB each. My PC is Windows 10 64bit, Asus Z97-P m/b, 8GB memory, i5 4460 CPU. I ran a CrystalDiskMark x64 test 3 times on it while it was formatted using MBR and got this:

MBR average results (all MB/s): - Read SEQ Q32T1 40 - Read 4K Q32T1 1.47 - Read SEQ 142 - Read 4K 1.22 - Write SEQ Q32T1 101 - Write 4K Q32T1 8.7 - Write SEQ 112 - Write 4K 8.5

Having a sadly large amount of spare time, I backed off the data (about 750GB), reformatted to GPT, in this case as a single 2TB partition, copied the data back to the disk, and ran the tests again:

GPT average results (all MB/s): - Read SEQ Q32T1 165 - Read 4K Q32T1 1.83 - Read SEQ 170 - Read 4K 1.5 - Write SEQ Q32T1 135 - Write 4K Q32T1 8.7 - Write SEQ 138 - Write 4K 8.6

So the SEQ Q32T1 results are much, much higher with GPT, and all other results are higher with GPT though surely not always significantly.

I'm certainly no expert as regards the actual everyday significance of these differences, but I'm tempted now to use GPT whenever I think I can get away with it (ie avoid old operating systems that can't read it).

Improve this answer
5
  • 3
    I doubt this difference is due to the MBR->GPT change. The MBR test is suspiciously close to the ~40MB/s limit of drives connected over USB 2. The Samsung D3 is USB 3, I suspect a fallback to USB 2 in your MBR test (did you use the same port?)
    – 0xF2
    Feb 21, 2016 at 19:51
  • Yes I used the same port, the drive was plugged in the whole time (USB 3.0 m/b integrated port).
    – JumpingJumping
    Feb 21, 2016 at 19:59
  • 7
    Partition table can't improve speed in any way. Something is wrong in your test.
    – Pilot6
    Feb 21, 2016 at 20:09
  • 8
    GPT and MBR data structures are both so simple that any performance difference caused by them should be tiny. Thus, either you've uncovered a hugely embarrassing bug or there's something wrong in your test methodology. I note that you created partitions of different size, for instance, for your two tests, and that could have a significant impact. If you did a file-level backup and restore, you would have changed where files reside and their fragmentation, which could affect results. In other words, you've got several variables, and so cannot determine which one caused the results you see.
    – Rod Smith
    Mar 18, 2016 at 13:17
  • 2
    Weird, because partition tables are remembered by an OS (stored in RAM), once they are loaded. Write speed of files is affected by filesystem type, and nature of files (few big, or millions of small). Difference between MBR /GPT could by just tiny (milliseconds and less) lag, which happens when loading partition table... And, this table isn't reloaded, until disc is unplugged, or requested (change to partition structure by some app).
    – kravemir
    Jan 1, 2018 at 7:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .