The Magic Behind APFS: Copy-on-Write

What is copy-on-write and how does it work?

The process of writing to disk occurs when the user saves modified versions of existing files. As you may already know, the file stored on your computer occupies physical space on the storage disk. Prior to APFS the changes were written onto the same storage blocks that contained the original files. While it may be convenient for tiny changes (let’s say you change two words in the article you’re working on), the problem is if anything goes wrong in writing the revised version of the file, both the old and new versions will be lost.

There is another thing that needs to be considered as well: overwriting data causes inconsistency, because when the system overwrites the data it needs to write over its blocks of storage, some of which represent the old state while others represent the new, changed state. The copy-on-write technique eliminates that by always allocating new data blocks and marking the old ones for reuse instead of overwriting the data in place. This technique is in line with the wear level protection that the TRIM command brings to SSDs, preventing individual memory segments from wearing out prematurely – an important factor to consider with flash storage.

Let’s assume that your article is physically saved on two blocks allocated on the startup disk; in HFS+, when you edit the file, the changes are reflected in just one of the two allocated blocks.

With copy-on-write the changes are written to a newly allocated block, not on either of the original two blocks. So, when the write happens, in effect there are two copies of the same file on the disk: the original two blocks, which together make up the first version, and the first block and the new block, which make up the changed file. The system then marks the block that was occupied by the old file as available for reuse and will delete them using the trim command when needed.

It may seem like an overhead, but it comes with a major advantage that enables built-in versioning which was previously done by software. This means that the system is able to keep a copy of the directory and other file metadata without additional effort and can provide a snapshot of all the files in a volume at any given moment. If something happens, such as a power outage or system crash, you are able to retrieve the old file from the snapshot or revert all files to that previous state.

Snapshot technologies: copy-on-write vs redirect-on-write

All this is possible thanks to the snapshot technology that Apple applied with APFS: copy-on-write. A snapshot is a locally stored, space efficient, point-in-time, read-only virtual copy of the volume – see mobile Time Machine. Snapshots can be implemented in various ways, but the two most popular are copy-on-write and redirect-on-write (RoW).

The first copy-on-write snapshot stores only the metadata describing where the original data is located. As the blocks of the original volume change (i.e. you start editing the article saved in Word format) the original data is copied into reserved storage set aside for the snapshot before the data is overwritten. This process maintains snapshot data consistency with the time the snapshot was taken.

Redirect-on-write takes another approach: in this case the system uses pointers to represent a volume, and when the block is modified the storage system redirects the pointer for that specific block to another and writes the data there instead, hence the name. The snapshot system is aware of where the blocks comprising a given snapshot are, and when needed it simply uses these pointers to access the required blocks.