Login
How do APFS volume roles work?
Since Catalina and Big Sur, macOS has started up not from a single volume, but a whole boot volume group. Among those are the System and Data volumes, intertwined by their firmlinks, a paired Recovery volume, and hidden volumes for virtual memory swap space and preboot firmware. To help macOS know which is which, each of those has a role assigned. This article explores how that works, how you can hand-craft your own Time Machine backup volume, and wonders what a Sidecar backup is.
Volume roles
Tucked away in the superblock of each APFS volume is an unsigned 16-bit integer setting that volume’s roles, chosen from 18 values ranging from None to Prelogin. Although I’m sure I’ve seen these disclosed in Disk Utility in the past, at the moment it appears the only way to read a volume’s set roles is in the command line, using the diskutil command tool, which can also create roles for a new volume, and change them for existing volumes.
The volume superblock of those that are part of a boot volume group also contains a UUID identifying that group.
Boot disk structures on Intel and Apple silicon Macs differ, as shown in the diagrams below.
That on the internal storage of Intel Macs consists of two partitions, of which only one is an APFS container.
Apple silicon Macs have three APFS containers, with their own volume groups.
According to Apple’s ageing APFS Reference, now over four years since its last update, roles found in Macs include:
- System (S), for a bootable system,
- Data (D), for mutable system components and mutable data,
- Preboot (B), for boot loader ‘firmware’,
- Recovery (R), for a Recovery system,
- VM (V), for virtual memory swap space,
- Update (E), whose purpose isn’t clear,
- XART (X), for hardware security on Apple silicon,
- Hardware (H), for firmware data in iOS, but also present on Apple silicon,
- Backup (T), for Time Machine backup stores.
There are also some that may not be encountered on Macs:
- Enterprise (Y), for enterprise-managed data in iOS,
- Installer (I), for install logs etc.,
- Sidecar (C), for Time Machine.
Finally, there are three that don’t currently have a documented character code:
- User, for Home directories,
- Prelogin, for system data used before login,
- Baseband, for radio firmware in iOS.
Using volume roles
You can view, set and change volume roles in the diskutil command tool, using its apfs command set. Although not listed now by Disk Utility, the commanddiskutil apfs list [containerReference]
displays role information about every volume in the container with the given reference. Omit that option and you’ll get information for containers on all mounted disks. Passing a container reference of disk9, for example, might reveal that volume disk9s1 has a Backup role, when it’s the current Time Machine backup store.
This is potentially useful information when you’re trying to understand some of the complex structures that can occur within containers. If you follow Apple’s advice when creating multiple boot volume groups, you’ll install two or more versions of macOS within the same container. If anything goes wrong with that, then it’s essential to be able to identify which are within each boot volume group, something that should be shown clearly by diskutil apfs list.
When adding a new APFS volume to an existing container using the addVolume command, you can pass an option -role to set its role using the single characters given in the lists above, such as T for a Time Machine backup store. If that option is omitted, then no role is assigned as a default.
You can change the role of an existing APFS volume using the changeVolumeRole (or chrole) verbdiskutil apfs chrole [volumeDevice] [role]
for example,diskutil apfs chrole disk9s1 T
to set disk9s1 to a Time Machine backup role.
This enables you to investigate how volume roles work.
Investigating backup roles
There are enormous problems in trying to perform surgery on boot volume groups, as you’re unable to pair System and Data volumes with firmlinks, or set the volume group UUID in each volume’s superblock. But there are two roles that merit further investigation, Backup and Sidecar, both apparently for use with Time Machine backup stores. I have seen it suggested that older Time Machine backups are stored on volumes with a Backup role, while newer backups are on those with Sidecar roles. So I created two test volumes, both using case-sensitive APFS, as Time Machine likes.
The Finder displayed the Backup volume using its distinctive icon for Time Machine backup stores, and Time Machine appeared happy to add it as a store, although it would need to change the volume’s permissions to set the User to read-only access.
The Sidecar volume vanished from the Finder’s normal list of mounted volumes, although it remained accessible in /Volumes, which it was shown with the regular volume icon, not that for Time Machine backup stores. That’s very different behaviour from current Time Machine backup stores. There’s another problem with the explanation given for these two roles: older Time Machine backups are made to HFS+ not APFS volumes, which don’t have volume roles at all.
Apple’s other use for the name Sidecar refers to the use of an iPad as a secondary display for a Mac, and doesn’t involve APFS volumes at all. So I’m left wondering whether Sidecar volumes are the unused remains of an old now-abandoned backup project, or the promise of something in the future.
Key point
Discover and investigate APFS volume roles using the diskutil apfs list command, passing the reference to a container, e.g. disk9, if you wish to be more specific.
