Last Week on My Mac: The extent of APFS’s problems

Every Mac user should be very interested in what happens with Apple’s new file system APFS, because it is the strongest indicator of Apple’s commitment to the platform.

Currently, every iOS device running 10.3 and later is running APFS, seemingly fairly happily. In fact, in the vast majority of cases, so happily that the user isn’t even aware that its file system has changed.

In contrast, only a small minority of Macs start up from an APFS drive: those which have been upgraded to (or shipped with) High Sierra, and boot up from an SSD. If you’re one of the millions whose Mac starts up from a Fusion Drive, an Apple-only product which has been pushed very hard as an ideal compromise between the speed of an SSD and the low-cost high-capacity storage of a hard disk, then you have either not upgraded yet, or are running High Sierra on Apple’s old HFS+.

In theory, in a few weeks or months time, a High Sierra update will bring APFS to Fusion Drives, and possibly conventional rotating hard disks (that seems less certain), and we’ll all move on, upgrade to High Sierra, and live happily ever after. If you’re confident that will happen, then you should listen carefully to Tim Standing, in his presentation at the MacSysAdmin conference in early October.

Tim – an immensely knowledgeable and experienced Mac software engineer, who for more than twenty years has been half of SoftRAID – draws attention to one of the adverse effects of copy-on-write, perhaps the single most important technology behind APFS. Copy-on-write is the heart of snapshots in APFS, its support for versioning, even the increased metadata protection which makes journalling unnecessary.

I have previously shown how copy-on-write works in the context of a single edit, and versioning. Let me illustrate its downside the same way.

copyonwrite1

Let’s start with a single continuous file on our storage. The ‘chunk’ which this occupies (shown in green) is known as its extent. Now, edit it in three sections.

copyonwrite2

That single extent is changed into a total of seven extents which together make up the file. If the file is being versioned, the three brown areas in the original extent would remain part of the previous version: we’ll ignore that here. Now, let’s edit the file a second time, changing three sections of its data again, two from the original extent and one from the previous edit.

copyonwrite3

After just two editing sessions, our single-extent original file has fragmented into no less than thirteen extents.

On an SSD, this poses no particular problem, although the file system is going to have to keep track of a very large number of extents. This makes APFS significantly more computationally intensive than HFS+, but then the older file system was designed for 68K Classic Macs with their pedestrian processors.

copyonwrite4

On a rotating disk, as Tim Standing says, everything starts coming to a grinding halt. To play that movie or audio, macOS needs to stream it continuously, which means seeking to each of those thirteen extents. Multiply that through the many files in macOS which your Mac needs to access, and you can see why the performance of APFS on rotating disks is far inferior to that of HFS+.

That is, though, something of a worst case. There are at least four solutions which Apple will be considering.

Tim Standing is of the opinion that Apple will end up layering APFS with CoreStorage, a project which he thinks could be completed quickly and simply. Another solution would be to turn copy-on-write off when APFS accesses hard disks, something Apple has apparently claimed it could do, but hasn’t done so yet.

The classic answer to file fragmentation on hard disks is to continuously defragment, which we are used to on HFS+. Whether that would prove feasible for the continuous and extreme fragmentation resulting from copy-on-write is unclear, though.

The fourth potential solution lies in the fact that copy-on-write is not an all-or-nothing technique, but can be implemented with different degrees of granularity. APFS decides how finely to fragment files, and the larger the extents used, the less the dangers of severe fragmentation.

copyonwrite5

By requiring larger extents to be involved in copy-on-write, APFS could, for example, limit the number of fragments resulting from the example editing process to seven rather than thirteen. The trade-off is that the benefits are also reduced. Perhaps Apple’s engineers are currently performing this sort of tuning to arrive at the best compromise for rotating disks.

Little of this has any bearing on APFS for iOS, but is crucial to the future of macOS. Like it or not, many Mac users are going to relying on rotating hard disks for years to come. They may not boot from them, but Time Machine backups and other mass storage systems reaching beyond a few terabytes will remain of great importance for the foreseeable future. And even as I write this, Apple is still selling 2017 iMacs with hard drives, and Fusion Drives.

In the coming weeks and months, Apple will demonstrate its commitment to macOS in APFS. If we’re left waiting and wondering, we’ll know that the Mac’s days as a serious computer platform are numbered, and Apple will be content to sell pretty laptops as iPhone accessories.

(Thanks to Michael Tsai for drawing my attention to Tim Standing’s presentation at MacSysAdmin 2017.)