We’ve been experimenting with Apple File System (APFS) on the Mac since it was introduced in macOS 10.12.4. Though APFS brings many advantages over Apple’s other file system, HFS+, so far performance speeds (reads and writers) aren’t one of them. I’ll walk you through what we’ve found so far at TMO.
Note that APFS is not yet offered in Disk Utility or elsewhere in the Sierra user interface—It’s strictly a command line option for now. I recently showed you how to start playing with it, but today we’ll talk about whether you should you experiment with APFS sooner, rather than later.
Why Do We Need APFS, Anyways?
This new way of formatting drives is meant to deal with limitations of the almost 30-year-old HFS+ file system. At its core, these are the modern file system features lacking in HFS+:
- Nanosecond timestamps
- Allowing concurrent access, for more than one process to access the file system at a time
- Checksumming
- Snapshotting
- Sparse file support
- A better implementation of hard links
HFS+ is also, at its core, case insensitive, which led Linux founder Linus Torvalds to call HFS+ “probably the worse file-system ever.” Granted, you can make an HFS+ volume case sensitive (meaning Mac is different from mac), but that’s through external patches.
APFS addresses those limitations. It also includes optimizations for flash and solid-state drive (SSD) storage. Encryption is natively supported, unlike with HFS+.
Sounds Great, so Why Not Get Started Right Away?
Slow your roll just a bit, because APFS isn’t perfect (yet?). Dave Hamilton and I have been experimenting with APFS, and it doesn’t seem to live up to all of the expectations yet. One of the boasts about APFS is that it is supposed to significantly increase read-write speeds on iOS and macOS. Our experiences, so far, haven’t shown that. In fact, they’ve shown the opposite.
Mr. Hamilton connected a Samsung 840 EVO 250GB SSD drive to his iMac using an OWC Thunderbolt Drive Dock, and first alerted me to the disparity in speeds. His results were as follows:
- HFS+ Journaled, Encrypted: 497MBps Read, 265MBps writes
- APFS: 435MBps Read, 202MBps writes
Next, he tried with a Seagate 5TB rotational drive. In this case, the APFS drive was, in fact, faster.
- HFS+ Journaled, Encryped: 212MBps reads, 170MBps writes
- APFS: 212MBps reads, 192MBps writes
I decided to try replicating Dave Hamilton’s results, and took screenshots of the speed test. I’ll let the images do the talking. These tests were completed using an internal Crucial MX300 525GB SSD operating at SATA 2.0 speeds.
As you can see, my results were similar to Dave Hamilton’s: the HFS+ drive was significantly faster than the APFS volume.
Does This Mean APFS Sucks?
Not necessarily. Let’s remember that, as far as we know, APFS is stil in development. There’s a reason the new file system isn’t available in the user interface yet,. It’s reasonable to think this is due to more than just the fact that you can’t yet use it for your startup drive or Time Machine. It’s very possible that developer debugging hooks are still in the APFS drivers. Also, Apple might not have finished optimizing the file system just yet.
There’s too much we don’t know. For instance, how will APFS handle smaller file reads and writes? Our tests were with 5GB test video files, which is far different from what your average user handles on a minute-to-minute basis. To be fair, I repeated the tests with a 1GB test file and got the same results, but my argument still stands: APFS could well be much faster with smaller files.
You Can Only Experiment if You Like the Command Line
It is important to note that the macOS Sierra user interface only allows you to perform read and write actions on an APFS drive. Creating the volume, erasing it and reformatting it as APFS, and moving the volume all have to be done from Terminal. Disk Utility does see the drive, but can’t format it as APFS. All you can do on an APFS drive from Disk Utility is format it as another file system.
Other Oddities With APFS
I’ve created and blown away several APFS volumes already, testing the process and trying to break it. I succeeded once. The first time I created an APFS volume on my internal SSD, that disk wasn’t accessible. I couldn’t write to it, couldn’t run a speed test on it, and found that it was only accessible from the root user. When I deleted the partition and recreated it, everything worked fine. Strange.
Why Would I Want to Play With APFS Now?
If you’re a developer or consultant, it’s important to start getting to know APFS sooner rather than later. You’ll want to know how to go about creating a drive. You will likely need to test its capabilities for yourself. There are plenty of reasons to try it out now, but there are also reasons to steer clear. If you regularly edit large video files, APFS isn’t for you (yet?). The moral of the story is that we need to keep watching this new file system and see if it eventually lives up to the hype. For now, at least, it’s noticeably slower than HFS+ with large files on an SSD. Nevertheless, the fact that it addresses the limitations of HFS+ might make the performance hit worthwhile.
My question is, does APFS eliminate the horrible delay with multiple spinning drives attached.
My dad has a MacBook Pro with four or five hard drives attached, all spinning HDs. When he accesses a file dialog window, he has to wait for all the drives to spin up before he can do anythjng, even if he is saving to the boot drive.
I could agree with the statement that case sensitivity is only a problem if you are not accustomed to it. The key rebuttal is that 99.9% of humans are not accustomed to it. But, even then I’ll even argue that those that are, can at times have problems and the complexity added far outweighs any perceived theoretical benefit.
Yes, back in the 70s for me too, the most insidious bug I ever encountered was caused by case sensitivity . It took over a week, despite many eyeballs from people totally experienced with case sensitivity to finally find this simplest of issue. Easily the worst bug in my life from an effort/impact over lack of complexity ratio. It’s time for the geek argument for case sensitivity to die. Yes, I have often argued the geek purity of methods against practicality, but in this case, it’s time for the geeks to drop the theory and get real
@3454 I don’t know the details of that Git exploit, but might case-insensitive systems have been vulnerable because Git was made first by the Linux guys on case-sensitive file systems so had some baked-in wrong assumptions?
@3728 I hear and think I understand your argument. Case-sensitivity can definitely cause some headaches if you aren’t accustomed to it. However, it can also be of great benefit. Think back to December 2014, when the vulnerability within git was discovered. Linux users weren’t affected, but Windows and Mac users certainly were. Why? Because their file systems were case-insensitive. Sure, HFS+ can preserve case, but OS X was vulnerable to that git exploit solely because it is a case-insensitive file system.
@jasonondssign Thanks, you’re right. Fixing it now.
Both your speed test screenshots say: “On an internal APFS volume”. I think the second should be HFS+.
I most strongly disagree with the allegedly esteemed Linus Torvalds. I have never, ever understood the fascination, nay, religious attachment to case-sensitive filesystem namespaces that many Unix (and now Linux) people have. Frankly, I consider case-sensitivity in file systems, programming languages, and command interfaces to be absolutely anethema.
And I’ve seen a lot of filesystems since my first computing days as a teenager in 1974.
The best possible filesystem namespace for ordinary people is one that is case-insensitive yet case-preserving, like HFS, HFS+, and NTFS. I’m hoping that APFS has a way of continuing that tradition.