macOS has actually supported Apple’s new file system APFS on Fusion Drives for well over a year: beta versions of High Sierra could convert Fusion Drives to its version 2 APFS between June-September 2017, but this support was pulled at the last minute from High Sierra’s release version. When you now upgrade a Mac with a startup Fusion Drive to Mojave, that drive will be converted to APFS; you don’t have an option.

Before explaining how Mojave’s version 3 APFS handles Fusion Drives, let me remind you how they work in good old HFS+.

When formatted in HFS+, Fusion Drives use an intermediate layer, CoreStorage, to get their two disks to look like one. Use the diskutil list command and you’ll see something like this.

Here, there are three disks:

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

The hard disk in the Fusion Drive consists of three partitions or volumes:

• 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 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 disk2 (referred to as a Logical Volume).

Although it had been suggested that High Sierra might use the same approach as CoreStorage, what is delivered in Mojave is quite different.

In APFS, there are still three disks:

• /dev/disk0 is an internal 2 TB hard disk, part of the Fusion Drive;
• /dev/disk1 is an internal 120 GB SSD, the other part of the Fusion Drive;
• /dev/disk2 is an APFS container consisting of the Fusion Drive as a whole.

The hard disk in the Fusion Drive has one declared volume:

• disk0s2, an APFS secondary physical store, which is designated for auxiliary use.

The SSD also has a single declared volume:

• disk1s2, the APFS main physical store.

The APFS container for the Fusion Drive as a whole has four volumes:

• disk2s1, the main storage volume containing the files seen by the user and mounted at /;
• disk2s2, the 42 MB pre-boot volume;
• disk2s3, the ‘hidden’ 512 MB Recovery partition;
• disk2s4, a 3 GB virtual memory store, which is mounted at /private/var/vm.

These precisely match the volume layout on the APFS ‘synthesised’ /dev/disk1 in normal APFS-format storage consisting of a single physical store. There are, though, two traps for those who need to refer to volumes by their disk identifiers: with a single-device APFS drive, synthesised volumes are partitions of /dev/disk1, but on a Fusion Drive they are partitions of /dev/disk2; designations in APFS are very different from those in HFS+.

Disk Utility’s simplified view shows only /dev/disk2, the Fusion Drive as a whole. At the top level, it confirms that it has a standard GUID Partition Map, and claims the capacity of the total of its two components.

The container-level view shows disk2s1 and disk2s4 in reverse order, but doesn’t show the pre-boot or Recovery volumes, which could be confusing. Instead, it reports 2 Not Mounted, presumably disk2s2 and disk2s3, which are here claimed to amount to nearly 10 GB, and a spurious Free, which isn’t a volume at all.

Finally, its volume view shows more than just disk2s1, and is really the current allocations within the /dev/disk2 container. I find this confusing, particularly in comparison to the diskutil apfs list results shown above.