APFS (Apple File System) Key Features

APFS (Apple File System) is a next-generation file system developed by Apple to meet the needs of today’s users. It was introduced at the Apple developers conference (WWDC) in June 2016, and was presented with iOS 10.3 a year later, on March 27, 2017.

What is APFS? – The Apple File System Explained [Video]

Video uploaded by Computer Clan on October 12, 2017

APFS (Apple File System): Key Features with Examples in Simple Words

While the sensational iPhone 7 (PRODUCT)RED captured everyone’s attention, all the features and benefits the new file system went unnoticed. APFS supports a range of firmware, including tvOS and watchOS, and replaces the nearly 30 year old HFS (Hierarchical File System) and HFS+ (Journaled Extended) file systems. It comes with the 10.3 version of iOS and later (for iPhone/iPod/iPad), and with macOS High Sierra 10.13 and later (for desktops, but currently in its beta version). Instead of listing the main innovations and commenting on them, we would like to make a point of highlighting the benefits for common users, without all the numbers and geeky specifications, just simple terms.

By the way, you will get additional free space on your iPhone/iPad after installing iOS 10.3:

In this article, we would like to focus on the macOS side of APFS instead of iOS. Today, we use it to operate hundreds of gigabytes of private data, photos, HD media, and store it on high speed flash drives. That’s why the Apple File System is primarily focused on optimization, speed, and low latency for flash (NAND flash in i-devices) and solid-state drives (SSD in Mac), but still can be used with HDD. Due to it being 64-bit instead of 32-bit, APFS supports large files. And, as we supposed, a lot of security improvements, data resolution in nanoseconds, faster animations, and the possibility to recover data immediately from previous points in the past.

You may pick up a quick volumes comparison, published at the developers library:

As previously stated, APFS is optimized for SSD, and there will not be a huge difference in speed from the common HDD. Here are some speed tests with the old HDD:

Key features (in no particular order):

Clones

The first feature we would like to talk about is called “Clones”. It makes a copy of a file or directory on the same volume without occupying additional space for it. You may notice similar technology in the ZFS file system of Solaris OS from Oracle back in 2005. When you make a copy of a file in HFS/HFS+, the system reads metadata first, and then writes it on free space. Such an algorithm overloads the main processor and hard drive. In APFS, the system only makes a copy of a link to a file (it is called a hard link) without the duplication of data. Such cloning (or copying) happens immediately. When you modify the clone, or make some changes to it, the file system writes only the data change – therefore the new file system can operate with more amounts and variants of “big and heavy” files, and demands less space on the SSD at the same time.

Snapshots

Another innovation around fast data recovery was developed to make the operation system work in a more efficient and stable manner. Snapshot is just like “photo of volume” that proceeds in real-time. It is a read-only instance of the file system, and offers to revert changes to a given point in time. For example, you have a volume on an external drive with 2 files: install.dmg and welcome.key presentation. A “snapshot” of this volume will only contain names of the files and the data blocks that respond to them, so there is no physical information of files in the snapshot. It only contains the names and blocks that respond to them “in the moment”. Blocks that have been written into the snapshot are closed, so you do not have the ability to move, rewrite, or delete them. And, if we delete, for example, install.dmg and make some changes to our presentation – original data blocks will not be affected. This mechanism does occupy some additional space, but it allows APFS to instantly go back and recover a volume to the point in time a snapshot was created.

Space Sharing

Imagine you have an iMac with a 1TB drive, and need to install the OS X El Capitan, and a beta version of a new macOS High Sierra. Right now, in the beta version of macOS High Sierra with APFS, you cannot boot from an APFS-volume, or use it with Time Machine, so you have to create two HFS+ volumes (for example, in half, 500GB each). With “Space Sharing” you do not have to manually set volume sizes with the help of Disk Utility. Inside the logical part of the drive with the APFS-volume, there is a container that consists of all volumes. Those volumes can easily increase or decrease within a container with no action from the user, or the need to manually select volume sizes. As far as the iMac, if there are two APFS volumes instead of two HFS+ volumes on the iMac’s drive, both operation systems (El Capitan and beta High Sierra, as we discussed) will offer 1TB of free space each. The free space, or rather just space used by the “first” operation system, El Capitan, will be unavailable to our “second” operation system, High Sierra. This solution helps to operate and manage the amount of volumes in more efficient ways.

Crash Protection (Copy-On-Write metadata) and Atomic Operations (Linearizability)

First, we need to talk about this term in concurrent programming. Such operations proceed in databases or operation systems uninterruptedly, indivisibly and cannot be simplified or divided further. The atomic operation cannot remain “undone” if it is interrupted, or else: it can only be in a state of “done” or “undone”. POSIX-certified secure file saving takes place when we save a file in the application, and memory data uploads to a temporary file on a drive. Then, after the application makes sure all data from memory uploaded fully and with no errors, it requests the operation system to make a “rename”. The current renaming operation (or process) is atomic and, as we mentioned above, can only be just completed or uncompleted. To achieve this, the operation system moves a temporary file to a saving place (a file keynote-presentation, “MakeMoneyFast.key” or, for another example, a document file “Meeting_report.pages” from /var/tmp/meeting_report.pages to ~JohnAppleseed/Documents/meeting_report.pages) and removes the previous one.

But, what happens if we want to save a folder or a bundle (.rtfd or .app)? For example, we’ve got a bundle, ~JohnAppleseed/Documents/JohnSarahWedding.rtfd, which contains simple text and a few photos. When we make changes and save them, the application fully overwrites the bundle (and not only the text and photos with changes). But with POSIX, saving is not allowed to the place where the data has already existed, so the operation proceeds in the following way: first, the document moves away from ~JohnAppleseed/Documents/ and gains free space at the same time. After that, the temporary file /var/tmp/JohnSarahWedding.rtfd gets saved as an empty space. This kind of operation does not belong to the atomic group of operations, and remains completely unsecured. You will lose the document through either operation system errors which happened while saving, or if you lose the power source.

Obviously, you do not want to lose a document or allow a chance for that to happen. That is why in APFS we got a new, no POSIX-compatibility operation of saving folders that is atomic and secure. When the application proceeds to save a folder, a temporary and a regular file trade places with each other. This operation is atomic and secure, made by the file system, it shows up as the crucial feature of the APFS called Copy-On-Write.