30

GPT (GUID Partition Table) partitioning has some benefits over MBR (Master Boot Record), including Support for:

  1. More partitions (128)
  2. Drives larger than 2 TB

But are there any other benefits like less likelihood of corruption? (The two HD failures I've had were corrupt MBRs). Or are you just playing wack-a-mole where the GPT then gets corrupt in the same way?

Clay Nichols
  • 5,264
  • 28
  • 82
  • 103
  • 2
    Why is the corruption happening in the first place? Is it just that other sectors can get corrupt without being detected? – pjc50 Aug 17 '16 at 11:10
  • In general it's more likely that some software corrupts or changes the partition and boot sectors than a hardware defect will. In any case having a backup is beneficial. – U. Windl Nov 25 '22 at 14:30

2 Answers2

37

According to Wikipedia, there is redundancy in the GPT scheme. The GPT table is written at the beginning of the disk, as well as at the end of the disk (see image). In addition each GPT table has a CRC32 checksum.

enter image description here

The redundancy is not available in the MBR scheme (which only occupied the first 512 bytes of a disk). The extra redundancy would allow for more resilience against corruption. The CRC32 checksum allows the system to detect which of the two tables is the correct one to be used to repair the other.

nixda
  • 26,823
  • 17
  • 108
  • 156
mtak
  • 16,513
  • 2
  • 52
  • 64
  • 1
    I wonder why they didn't go with three ... – Mawg says reinstate Monica Aug 17 '16 at 07:51
  • 6
    @Mawg Well, where would they put the third copy? Beginning of disk and end of disk are obvious places that don't mess with anything and are unlikely to be corrupted at the same time, but you can't just put a bunch of data in the middle of the disk. – Luaan Aug 17 '16 at 08:03
  • It doesn't matter **where**, just that there are three, so that you can have a "majority wins" vote, which you cannot with two. – Mawg says reinstate Monica Aug 17 '16 at 08:25
  • 3
    @Mawg: wel, putting the third copy in the middle of disk sectors will enforce you to have a partition split there. In this case you won't be able to move or shrink partitions cross that line (I mean LBA sector:). So that's impractical. And if you put 3rd one near 1st or 2nd one, then likeness of corrupting all the copies stays almost the same, IMHO. – saulius2 Aug 17 '16 at 08:46
  • 10
    @Mawg Remember that each copy has a CRC checksum, so that should tell you which of the two copies is corrupted on its own... – MathematicalOrchid Aug 17 '16 at 09:06
  • And if neither is corrupted? I.e. each CRC is valid (for its own data), but the data do not match? I have seen that often enough in my decades of coding. Which one of two to trust is always a difficult decision. Three makes that decision easier (imo - ymmv) – Mawg says reinstate Monica Aug 17 '16 at 12:01
  • @Mawg The problem is that putting it near the beginning or end means that if the beginning/end get corrupted there are high chances that you simply get two corrupted tables, which means the redundancy is useless. If you put it in the middle then you suddenly halved the maximum size of a partition on that disk. – Bakuriu Aug 17 '16 at 13:35
  • 1
    Cleverer people than me decided to put it front & end, so I cannot comment on why that would give you `high chances that you simply get two corrupted tables` (feel free to explain). To be clear - I don't care where they go (NVMEM on the motherboard might be a good idea). I simply contend that an odd number of copies of any data makes conflict resoultion easier than an even number. – Mawg says reinstate Monica Aug 17 '16 at 13:43
  • @Mawg Putting two copies of the GPT next to each other means there is a large chance that if one of those two copies gets corrupted, the other will as well. Thus the designers put the two copies as far away from each other as possible: one at the beginning, one at the end. A third (on disk) copy would either have to be adjacent to one of the two existing copies, and thus do little to help with redundancy, or be somewhere in the middle, and cripple partitioning options. An off disk copy is rather useless on a removable storage device, plus requires new hardware (eg. motherboards) to support it. – 8bittree Aug 17 '16 at 15:11
  • For the first part of your comment - it depends on how large the damage is. If less than the size of a GPT then conseuctive copies would not hurt. Why not chace it? Again, placement is someone else's problem. For me, the overriding concern would be to have an odd number of copies - however & wherever it is deemed best to do so. – Mawg says reinstate Monica Aug 17 '16 at 15:29
  • @Mawg "Placement is somebody else's problem" If you're going to have a third copy, it has to be put somewhere. It won't magically find its own place and deferring the decision to somebody else doesn't magically make a good option appear. Adding a second copy is a cheap and simple thing to do. Adding a third is not so simple because there is no obvious place to put it. The much simpler and effective way of keeping your data safe is to back it up. – 8bittree Aug 17 '16 at 15:39
  • Then why bother with two copies? ;-) – Mawg says reinstate Monica Aug 17 '16 at 15:46
  • @Mawg It's cheap. – 8bittree Aug 17 '16 at 16:02
  • 2
    @Mawg you're looking for a solution for a hypothetical problem. *If* the two GPT tables don't match and *if* their CRC32 checkums are both OK, then you have indeed the problem you're describing. This would realistically only happen because of a serious bug in the operating system. Taking into account the disadvantages and problems with a third GPT copy (I think you might underestimate how complex partitioning can get in server environments), as well as a regression in functionality, I can well imagine that the designers opted for the non-nuclear-protection option :) – mtak Aug 18 '16 at 07:31
  • 1
    Speaking of nuclear ... I doubt that updating both GPTs is an atmic action ;-) So, we update the first, then cut the power & now both have mis-matched content with a valid CRC. Given the sheer, mind-blggoling, number of hard-drives out there, I imagine that it happens often. But - to repat (my repetition) - I am a software guy and **do not like (or trust)** having an even number of copies of data. That - and no more - is all that I have to say :-) – Mawg says reinstate Monica Aug 18 '16 at 08:02
  • 1
    @Mawg "So, we update the first, then cut the power & now both have mis-matched content with a valid CRC." -- Then how would a third copy help in this scenario? – Kamil Maciorowski Apr 16 '18 at 11:33
0

The second copy of the partition table at the end of the device can have opposite effects, however:

Imagine you use a large disk that had GPT on it, and you decide to copy the image of a smaller GPT disk onto it (which was never a problem with MBR disks). The problem is that the software might locate the backup copy at the end of the device (i.e.: the obsolete partition table). Then both tables seem valid (CRC-wise), and the software might decide to use the one matching the disk size, copying the "backup" to the main one.

I was actually hit by such a problem when EFI and GPT were rather new.

U. Windl
  • 492
  • 4
  • 25