Not long ago, any article on the layout of macOS boot disks would have been short and sweet. When Apple added the Recovery volume, it might have stretched to two or three paragraphs before running out of steam. As I showed yesterday in my review of the volume structure of startup disks, this became more complex in Catalina, quite intricate in Big Sur, and even differs between Intel and M1 models. Navigating these volumes – particularly when you start looking at their interlinked folder structure – needs not one but several maps in macOS 11.

Compare an Intel Mac running Catalina with an M1 with Big Sur, for instance. The Intel Mac has two partitions, the standard hidden EFI partition, and its APFS container, which in turn contains one Volume Group and three additional volumes for Preboot, Recovery and VM. You can’t even summarise the partition/container and volume layout of Big Sur in a single sentence, and by the time you’ve also given an account of what appears in /System/Volumes, you’re running into multiple paragraphs.

At the top level, there’s the open question as to whether Apple is going to perpetuate the traditional EFI partition, as the M1 doesn’t of course have any EFI. No one seems to know what the EFI partition actually does now, but it’s been there since Macs transitioned from Open Firmware. While Apple has retained it, presumably for backware compatibility, on Intel Macs and external disks for the M1, the latter’s internal SSD gives us a glimpse of where it’s heading: two new partitions, one tantalisingly called Apple_APFS_ISC, the other Apple_APFS_Recovery, while dear old EFI is nowhere to be found. What exactly APFS does or is going to do with these two new partitions hasn’t been revealed, but the second hints at its use to support file system recovery.

It’s when you look in the /System/Volumes folder that it all gets more bewildering. In Catalina, this is the mountpoint for the Data volume. In Big Sur, it more resembles a beta-release: most of the items in a folder named Volumes aren’t volumes at all, but folders, it would appear. For example, there’s a folder named Recovery, although what we know as the Recovery volume (it’s an APFS volume, not a partition as it was in HFS+) isn’t a folder, and is unmounted anyway, until your Mac starts up in Recovery mode.

Some of the folders appear to have obvious purposes, for Field Service, for example, while others like xarts/xART are outright mysteries. Of the items there, that’s the one which seems to defy all conventional behaviour. On Intel Macs, it appears to be an empty folder named xarts, but on an M1 internal SSD it’s a volume named xART which is mounted there at the mountpoint of xarts, and is likely to contain at least one file. Yet on neither architecture is it listed among the APFS volumes.

The first time that xART appeared on Macs is in xartstorageremoted, the xART Remote Storage Daemon, which listens for storage access requests from T1/T2 chips. That could explain why it differs between an Intel Mac with a T2 chip, and an Apple Silicon Mac with its Secure Enclave integrated into the M1 SoC, where it might be a virtual APFS volume without any presence on disk. Why this has been left so visible in a release version of macOS is another part of the mystery. Perhaps Apple’s engineers just like teasing us.

There’s a bigger question about disk structure, though, and that’s the future of the GUID Partition Table (GPT) itself. Apple’s command tool for managing the GPT, gpt, remains incomplete and (inevitably) very poorly documented. In the man page it openly admits:
“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.”

Given the sustained engineering effort which has gone into the development of APFS, it’s hard to believe that it should rely on this “work in progress”. Yet Disk Utility still reports that it initially formats a disk in HFS+ before converting that to APFS, despite gpt claiming to be able to create APFS partitions/containers, which would surely be more efficient.

Next week, I move on to revisit the folders and firmlinks within the System and Data volumes, to update those maps for Big Sur. I’ll be taking my GPS.