If you’ve ever used a command tool which works with disks and volumes, you’ll be aware of the fact that what the Finder shows, and even what gets listed in /Volumes, is only a fraction of what macOS knows about.

According to the Finder, and /Volumes, at the moment this iMac has two storage systems accessible: its internal Fusion Drive, and an external RAID array which is used for Time Machine backups. Disk Utility displays them as two ‘disks’, each with a single volume. Type
diskutil list
in Terminal, though, and it tells me that my iMac has four disks (disk0 to disk3), with a grand total of 12 partitions, from disk0s0 to disk3s2. This article attempts to explain how this comes about, and how it works (differently) in APFS, and is part of a series which will eventually look at the boot process in its traditional form, in APFS, and Apple’s new Secure Boot.

When macOS encounters a physical or virtual disk, it is given a disk identifier, of the form /dev/diskN, where N is an integer starting from 0. My iMac only has two storage devices connected, but those are actually made up from six physical storage media: internal SSD and hard disk in a Fusion Drive, and an external hardware RAID system which presents itself as a single physical drive, rather than the four individual hard disks making up the RAID array.

So:

• /dev/disk0 is an internal 2 TB hard disk, part of my Fusion Drive;
• /dev/disk1 is an internal 120 GB SSD, the other part of my Fusion Drive;
• /dev/disk2 is a virtual storage device made by CoreStorage from my Fusion Drive;
• /dev/disk3 is the external 6 TB RAID array.

Each of the three physical drives then has a first ‘partition’ which is the GUID partition map, then two or more partitions, from s1 upwards.

The hard disk in my Fusion Drive has three partitions:

• disk0s1, a small EFI partition of just over 200 MB;
• disk0s2, the main storage volume which is managed by CoreStorage;
• disk0s3, the ‘hidden’ Recovery partition of 650 MB.

The SSD in my Fusion Drive also has three partitions:

• disk1s1, the small EFI partition as before;
• disk1s2, the main storage volume managed by CoreStorage;
• disk1s3, a Boot OS X volume of just over 100 MB.

CoreStorage then binds disk0s2 and disk1s2 together and presents the Fusion Drive as the virtual volume (Logical Volume) disk2.

My external RAID has only two partitions:

• disk3s1, the small EFI partition as before;
• disk3s2, the main storage volume itself, all 6 TB of it.

Hopefully that is all logical and straightforward, at least until we come to APFS. If you use the same diskutil list command on a Mac with a single internal APFS disk with a single user volume on it, you’ll see that things have become more complex. Your single disk, /dev/disk0, now has a “synthesized” twin /dev/disk1.

On /dev/disk0, there is a basic partitioning, in addition to the GUID partition map:

• disk0s1, the small EFI partition as before, although it is here over 300 MB;
• disk0s2, an APFS Container named disk1, with the main storage space.

The ‘synthesized’ /dev/disk1 then contains the important partitions, after an APFS Container Scheme which functions a bit like a partition map:

• disk1s1, the main storage volume, which is given its actual size, not its maximum capacity;
• disk1s2, the small Preboot volume, just over 20 MB;
• disk1s3, the ‘hidden’ Recovery partition of just over 500 MB;
• disk1s4, a VM partition of 1 GB or more, which is mounted at /private/var/vm to provide virtual memory.

The Preboot volume is new with macOS systems booting from APFS disks, and contains the EFI boot file, which was previously provided in the System volume. If you mount and examine it, you’ll see that it contains one or more folders named using UUIDs. Each of these corresponds to an associated System volume within that APFS Container, so allowing a single APFS Container to hold multiple bootable systems, each with its own EFI boot file, etc.

When you’re running High Sierra or later, you have another command option which provides even more information about your disks and their volumes:
diskutil apfs list

This displays the above information plus a lot more in a nice structured view, without the odd ‘synthesized’ confusion, covering each APFS Container, even giving the mount point of the VM volume on the startup disk. What I can’t show you yet is how a Fusion Drive fares in APFS, which is only officially supported in Mojave beta, of course.

Occasionally, I hear of users who have somehow ended up with Macs which don’t appear to have Recovery partitions, and can’t enter the Startup Manager. When Apple first introduced the Recovery partition, this was not uncommon, but should never happen now if a disk has been correctly erased, and macOS properly installed. Diagnosis starts with the two-word command in Terminal: diskutil list which should tell you exactly what is on the disk.

Damage to the GUID partition map or specific volumes can result in similar problems, and in most cases will need the disk to be erased and its contents reinstalled, if it can’t be repaired. Without a functioning Recovery partition, you’re then looking at Remote recovery, or starting up from a different disk, such as a USB memory stick with macOS installer on it.

APFS volumes have an additional level of ‘partitioning’ with their Container, which could in theory provide another point of failure. Experience to date with APFS has predominantly been with newer and SSD disks; when there is greater experience of its use on ageing SSDs and on conventional hard disks, this may prove significant. Time will tell.