What is the Mac file system and how does it work

The Mac file system is APFS, the scheme macOS uses to lay your data on disk. It puts volumes inside a container rather than a partition, shares free space between them and never overwrites a block in place. Those three choices explain most of what looks strange about Mac storage.

None of them is visible from Finder. All three surface the moment you open Disk Utility, read a storage bar or wonder why a number will not move.

What a file system does

A drive on its own stores numbered blocks and nothing else. It has no idea what a folder is, which blocks belong together or what any of them are called.

A file system is the bookkeeping laid over those blocks. It answers two questions. Which blocks hold this file and which blocks are free to write to.

The second question is where most Mac storage confusion begins. APFS answers it in a way that makes the figure in Finder less simple than it looks.

Why HFS+ ran out

macOS ran on HFS+ for close to twenty years. Apple shipped it in January 1998 with Mac OS 8.1, when a large drive held four gigabytes and spun on a platter.

Its limits came from that era. File identifiers were 32 bits wide, so one volume topped out near 4.29 billion files. Its date range stops on 6 February 2040. The assumptions underneath it, from block layout to how the catalogue got searched, were written for a moving head.

APFS became the default with macOS High Sierra in 2017 and has sat under every Mac startup disk since. Apple built it for flash storage from the first line, with encryption treated as part of the file system rather than a layer added over the top.

What follows is how it works. The head to head between the two formats is a separate question. This page does not answer it.

The container, a layer that did not exist before

Under HFS+ the arrangement was flat. The drive carried a partition table. Each partition held exactly one volume, with its size written into the table. Growing one meant shrinking another. Doing that to a live disk was the kind of operation people took a backup before attempting.

APFS puts a layer in the middle. The drive still carries a partition scheme. Inside a partition sits a container. That container has a fixed size. Volumes live inside it. A container can hold several.

Everything the volumes hold in common, free space, snapshot records and the crash protection machinery, belongs to the container rather than to any one volume. That is why Disk Utility asks you to repair a container before a volume. It also explains why erasing one volume out of a group tends to end badly.

Why a volume has no size of its own

Ask how big Macintosh HD is and there is no clean answer.

Apple states the rule plainly. The space available to a volume is the size of the container minus the space used by every volume inside it. APFS reserves nothing in advance. A volume takes what it needs and gives back what it stops using.

That is why every volume in a container reports the same free figure. The number shifts while you watch it for the same reason. Disk Utility does allow a reserve and a quota per volume, but neither is applied by default.

A container that starts a Mac is also fuller than it looks. From macOS 10.15 onward it carries at least five volumes. Three of them stay hidden.

Preboot, VM and Recovery stay shared rather than duplicated. Install a second copy of macOS in the same container and it gets its own System and Data pair, while those three stay as they were.

What a file actually is on disk

A file is not a lump of data sitting in one place. It is a record carrying a number, a set of attributes and a list of where its content lives on disk.

The number is the inode. APFS gives them 64 bits, which puts the ceiling above nine quintillion files on a single volume. HFS+ used 32 bits for the same job and stopped near 4.29 billion. Nobody is going to meet either ceiling. The width matters for a duller reason. Identifiers never have to go out twice. Reuse is the source of the kind of fault that restores the wrong file years later.

Extents describe the content itself. An extent is a start block and a length, meaning this file continues here for this many blocks. A file written in one go can have a single extent. A file edited across years has many, scattered wherever there was room at the time.

That indirection is what makes everything else possible. A clone is two files pointing at one set of extents. A snapshot is a record of which extents a whole volume held at a moment. Copy on write writes a new extent and moves a pointer rather than touching the old one. None of it would work if a file were a fixed run of blocks with its name stamped on them.

APFS also allows sparse files, where a run of nothing carries a length instead of a long stretch of written zeroes. A disk image set to grow to 100GB can hold 2GB of real content and take 2GB of real space. It is one reason the size Finder reports and the space actually consumed can disagree before any of the other mechanisms come into it.

Copy on write, the reason nothing is overwritten

Change a file on APFS and the old blocks stay where they are. The new content goes to free blocks somewhere else. The file system updates its pointers to the new location only after that write finishes.

The old blocks go back to the free pool when nothing refers to them any more.

This is what makes an interrupted write survivable. Cut the power halfway through a save and the pointers still describe the previous version, because nothing changed them. There is no half written file waiting to be repaired.

It carries a consequence people meet without knowing the cause. Freeing a block and deleting a file are separate events. A block with something still pointing at it never returns to the pool, which is the mechanism behind space that will not come back after a delete. The other half of that story is whether the data itself stays readable, which is what deleting a file on APFS actually removes.

Clones, copies that cost nothing

Duplicating a file on APFS copies no bytes at all.

The file system creates a second name pointing at the same blocks as the first. Both are real files, both are writable and neither is a shortcut to the other. They stay identical on disk until one of them changes. Only the blocks that differ take storage of their own.

So a four gigabyte duplicate can cost nothing on the day you make it, then start costing something as you edit it. Finder reports four gigabytes for each copy, because that is how much data each one contains. Neither figure is wrong. They just do not add up the way the words suggest.

Snapshots, a volume held still

A snapshot records what a volume looked like at one moment. It is read only. Taking one costs close to nothing, because it amounts to a set of references to blocks that already exist.

Read more: Why a macOS update needs more space than it says.

It grows as the volume moves on. Every block the live volume replaces has to be kept for as long as the snapshot points at it.

macOS does this to itself. From macOS 11 onward the Mac does not start from the system volume. It starts from a snapshot of that volume, which is a stronger guarantee than a read only mount, since what is running cannot be altered even in principle.

Time Machine keeps snapshots on the internal disk too. That is where a large block of space refusing to release comes from.

The volume group, in one paragraph

A startup container never holds one macOS volume. It holds a pair, treated as a unit that macOS calls a volume group. One member carries the operating system and accepts no writes at all. The other carries everything that has to change while the Mac runs. Cross volume links stitch them together well enough that Finder never lets on there are two. Why Apple split them, plus what to do when a third one turns up, gets why a Mac shows two Macintosh HD volumes.

Where encryption sits

Apple designed APFS with encryption as part of the file system rather than something applied over it.

Three arrangements exist. No encryption at all, a single key covering the whole volume or a multiple key scheme with a key per file and a separate key for metadata. Which of those you get depends on the hardware and the operating system underneath.

The structural point is where encryption attaches. It is a property of the volume, not of the container and not of the drive. One volume in a container can be encrypted while another beside it is not. Each carries its own keys.

How the Mac file system stacks up

Read it from the outside in. A drive carries a partition scheme. A partition holds a container. A container holds volumes. A volume holds files. A file is a set of pointers to blocks.

Three behaviours run through the whole arrangement. Space is shared rather than divided, so no volume has a size. Blocks land somewhere new rather than over the top, so an interrupted save loses nothing. References are counted rather than copies made, so two files can share the same data and a snapshot can hold a moment still.

Almost every Mac storage question that starts with why comes back to one of those three.