Inside the file system: 1 Disks and partitions

This is the first in a series of three articles looking at the internals of Mac file systems, the parts that Disk Utility refers to when it runs First Aid on them. You may see it report items like
Checking the partition list
But what exactly is the partition list? If there are problems with it, what do they mean, and what might I see as a result? If Disk Utility can’t repair those problems, what can?

Whatever the type of storage, whether hard disk or solid-state, its space needs to be organised so that it can store files and metadata. At the top level of the disk is the partitioning scheme. This divides the available storage into large contiguous blocks which can then be used to contain file systems, which deal with individual files and their structure into folders or directories. Conventional usage refers to these as partitions, but in APFS they are also known as containers. The scheme now used universally for macOS is the GUID Partition Table, shown diagrammatically below with the start of the storage at the top.

GPT

Near the start of the storage is a Primary GPT Header, which contains the table which maps out where the partitions are on the disk. This header is repeated at the end of the storage, as the Secondary GPT Header, which should of course remain identical at all times.

In the header, there’s an initial block containing information about the storage as a whole, followed by an entry for each partition. Those entries specify the type of partition using a GUID/UUID, give each its own unique GUID/UUID, give the start and end locations of that partition, its attributes, and name.

Following the header and its list of entries are the partitions themselves, each containing file-system specific data.

When First Aid checks the partitioning scheme, it works through each of these in turn to ensure that the list of partitions appears correct, and that the location of each partition appears correct. Errors in these may not be repairable, at least not without risking data loss. For example, if the start and end locations of two partitions overlap one another, there’s clearly an error but no simple way to determine what should be the correct values. This is where the Secondary GPT Header can help, provided that doesn’t have the same error.

First Aid also checks the one mandatory partition which is required on all macOS disks, its EFI System Partition, together with any booter partitions, and any used by Core Storage. Each of these is reported individually in its progress log, which should read something like
Checking prerequisites
Checking the partition list
Checking the partition map size
Checking for an EFI system partition
Checking the EFI system partition’s size
Checking the EFI system partition’s file system
Checking the EFI system partition’s folder content
Checking all HFS data partition loader spaces
Checking booter partitions
Checking Core Storage Physical Volume partitions
The partition map appears to be OK

Note that only the first two entries are concerned with the partitioning scheme as such. The remaining entries refer to hidden partitions which are required on macOS storage.

Because the same partitioning scheme is used by both HFS+ and APFS, which are file systems contained within partitions, checks and repairs are essentially the same regardless of whether the disk has been formatted using either file system. It’s only when you look inside containers that there are major differences. For information, you may encounter the following partition types:

  • EFI System Partition C12A7328-F81F-11D2-BA4B-00A0C93EC93B
  • HFS+ partition 48465300-0000-11AA-AA11-00306543ECAC
  • APFS partition (container) 7C3457EF-0000-11AA-AA11-00306543ECAC
  • AppleRAID partition 52414944-0000-11AA-AA11-00306543ECAC
  • Recovery partition 426F6F74-0000-11AA-AA11-00306543ECAC
  • Core Storage container (including HFS+ FileVault) 53746F72-6167-11AA-AA11-00306543ECAC

Partitions are of fixed rather than dynamic size, and can’t overlap or be divided over separate areas of storage. It used to be that changing the partition map by changing number or size of partitions was inevitably destructive, and resulted in the re-initialisation of that disk. More recently, it has been realised that, so long as partitions have adequate unused storage within them, many partition operations can be performed non-destructively, preserving the contents of file systems inside the partitions. Don’t rely on that though: it’s a bonus, not an expectation.

Errors in the partition information on a disk are just about the most damaging that can happen to any disk. Thankfully they are now extremely rare, and with the Secondary GPT Header can be completely recoverable. However, failure of a disk in the zones needed for the GPT headers is one compelling reason to discard that disk and never to trust it again.

Other than using Disk Utility, there are command tools available which operate on the partition table. Basic formatting and adjustments are supported by the normal set of verbs for diskutil, but to work at a lower level you’ll probably need gpt. Because the GPT controls the whole disk structure, these are formidable tools whose documentation leaves a lot to be desired. Indeed, the gpt man page warns:
“The development of the gpt utility is still work in progress. Many necessary features are missing or partially implemented. In practice this means that the manual page, supposed to describe these features, is farther removed from being complete or useful. As such, missing functionality is not even documented as missing.”

If you really do need to use gpt or mess with your partition table, it’s better to find an expert who can guide you through, and have that disk thoroughly backed up.

Reference

Wikipedia has a very clear and detailed account across different formats including macOS.