The last few major releases of macOS have brought structural changes to the layout of boot disks, and M1 series Macs are quite different from Intel models. This article summarises the volume layouts used in Monterey 12.1. To review those of earlier versions of macOS, see this article.

Although the changes between Big Sur and Monterey may seem minor, they’re particularly significant in determining which Recovery volume is used, as explained here.

Throughout these diagrams, Unix-style identifiers are only examples of what you might see, and are flexible in use. For example, a Preboot volume shown here as having an identifier of disk7s3 could be anything from disk7s1 to disk7s7 instead, and when in the container disk3 would be anything from disk3s1 to disk3s7.

Volume layout on Intel Macs hasn’t changed since Big Sur. There’s the traditional hidden EFI partition, and a single APFS container with the bootable system, consisting of:

• the SSV, a mounted snapshot of the unmounted read-only System volume named Macintosh HD, which forms the root of the boot file system. The snapshot is named com.apple.os-update- followed by its UUID, and the volume (hence its snapshot) is typically about 15 GB in size;
• the writable Data volume, by default on the internal disk named Macintosh HD – Data, which is normally hidden from view at /System/Volumes and accessed via firmlinks. On Intel Macs, this is given its full name;
• Preboot, a small volume of around 714 MB;
• Recovery, the Recovery Volume, of around 1.1 GB;
• VM, containing virtual memory caches, which is upwards of 20 KB depending on use.

Note that the Seal on the unmounted read-only System volume is normally broken, but it’s the snapshot which is the important one: that should be sealed, unless you have broken its seal intentionally.

Apple’s terminology for the SSV isn’t entirely consistent. In APFS reference documentation, it’s used to refer to the Sealed System Volume, whereas in its Platform Security Guide it means the Signed System Volume, although the top-level hash is known as the Seal rather than the Signature. Maybe it’s just a Signed and Sealed System Volume after all.

The internal SSD in an M1 series Mac consists of three APFS containers, and lacks the legacy EFI partition. Only the Apple_APFS container is normally mounted, and that has a similar structure to the boot container of an Intel Mac, or that of an external bootable disk. There are two significant differences, though:

• the Data volume isn’t named Macintosh HD – Data, as on an Intel Mac, but plain Data;
• the Recovery volume is the primary Recovery system for that copy of macOS, and is supported by a catch-all or fallback Recovery system in the unmounted Apple_APFS_Recovery container, which is larger at 5.4 GB.

M1 Macs are distinct in having this fallback Recovery system which makes them more robust in the event of damage occurring to the boot container on their internal SSD.

My final example layout shows a disk with a single APFS container containing two bootable macOS systems, typically on an external disk or the internal disk of an Intel Mac. Within the APFS container are two complete Volume Groups, but Preboot, Recovery and VM volumes are common to both systems. In M1 Macs, the Recovery volume there contains the primary Recovery system for both of the Volume Groups, with the Apple_APFS_Recovery container on the internal SSD as its fallback.

This demonstrates the economy of disk usage achieved by installing multiple copies of macOS in a single container. The disadvantages arise from the fact that all systems within that container share Preboot and Recovery volumes; when they’re derived from contrasting versions of macOS, that creates the potential for incompatibilities. Thus installing two copies of the same version of macOS in a single container is likely to be reliable; versions which are far apart could give rise to problems, and might be better in different containers, where they have their own Preboot and Recovery volumes.