Ever since the first beta of Sierra (Mac OS 10.12), I have been interested in Apple’s new file system, APFS. As the first new file system released by Apple in almost 30 years, I knew this file system would be built from the ground up using the best techniques for providing speed, reliability and features found in modern file systems. (For more on APFS, click here).
As soon as I could I was able to create an APFS volume on top of a SoftRAID volume, I started testing APFS for speed. I wanted to see if it was faster than the HFS Extended volumes I had been using for decades. I also wanted to test APFS with different RAID levels on both SSDs and HDDs. Would Apple’s promise that APFS was a “low latency” file system translate to faster reading and writing? Did APFS deliver faster speed on the HDDs, which are used throughout the film and video industry?
Also Read: Using APFS On HDDs … And Why You Might Not Want To; How to Revert a drive from APFS back to HFS+
For all my early testing, I used AJA System Test with files of differing sizes. AJA system test writes a single large file to a volume and reads it back to determine how fast the volume reads and writes file data. Results are displayed in a speed/time graph, which shows how much read/write speeds vary during the test. This makes it easy to see if the file system has to pause every so often to take care of housekeeping chores, leading to slower performance.
While some of the early releases of APFS resulted in volumes, which were slower than HFS Extended on the same hardware, it soon became clear that APFS was improving. After a few months, new versions of APFS gave the same results with AJA System Test as HFS Extended.
I always want to stress test software as much as possible—the faster the storage device the harder it is for the OS to keep up with. So what better way to do this than by using two of OWC’s upcoming ThunderBlades with a 2017 MacBook Pro? Each of these soon-to-be-released devices incorporates 4 SSD blades; using two of them to create an 8-blade stripe, I could get performance way faster than possible even with a single Thunderbolt 3 port.
So just how fast is the release version of APFS which comes with High Sierra? Can it keep up with HFS? To find out, I created an APFS volume using a beta copy of SoftRAID version 6 and two ThunderBlades.
I repeated the AJA System Test using a large variety of disks and RAID levels (created with SoftRAID). The speeds of APFS and HFS Extended volumes were always within a few percentage points of each other regardless of the type of disks or RAID level I was using.
So far, so good… However, after High Sierra shipped, I decided to dig into the performance of APFS even further. I had really only tested speeds with a single file operation; how would APFS perform with a more likely scenario—copying numerous files between volumes? To my surprise, I found that copying a large number of files from one APFS volume to another (on a second disk of the same type) was always slower than performing the same operation with HFS Extended volumes. The speed difference was most pronounced with HDDs—where APFS could take almost twice as long to copy—but also existed on SSDs, and even ThunderBlades.
I needed to thoroughly test the comparative speeds of APFS and HFS. So I created two source volumes, one APFS, one HFS Extended, both with High Sierra (macOS 10.13) installed. I also created two target volumes, again one APFS, one HFS Extended, on separate disks. I then used the Finder to copy four startup volume folders (Applications, System, Library and Users) from the APFS source volume to the APFS target volume. I repeated the test, this time copying the same four folders from the HFS source volume to the HFS target volume. Copying these four folders involves copying over 160,000 files, which total just over 12 GB in size. The Finder copying was timed using a stopwatch.
This test was performed several times using a 2017 15” MacBook Pro as the source, and either ThunderBlades, 10TB Hitachi SATA HDDs (connected over Thunderbolt) or a 960 GB OWC Extreme Pro SSDs (also connected over Thunderbolt) as the various targets. In the graph below (showing the results) you can see that each APFS volume takes longer to copy files than an HFS Extended volume on the same hardware. Copying files between two APFS volumes, each on separate HDDs, takes almost twice as long as using HFS Extended volumes.
The test results from AJA System test show that the speed of reading and writing from a single file is the same between APFS and HFS Extended. By contrast, the Finder copying tests show that the APFS can’t keep up when copying large numbers of files from one device to another. This is probably caused by the extra layers in the APFS file system, which are required to implement all the cool new features like copy-on-write and snapshots.
More on APFS:
It would be great if you could perform tests also using read/write sequential MB/s (QuickBench) adn read/write random IOPS (AmorphousDiskMark) with macOS Sierra, High Sierra and Mojave.
I wonder if Mojave will alter these copy issues. I hope you can find the time to repeat the above test using the Mojave beta just out. I am seeing a dramatic read write increase on my 512 GB internal on a new Mac Pro but so far haven’t messed with my external RAIDs.
So tell us how to not use APFS on High Sierra since it is slower than HFS+
Eric, it’s not slower in general, and in fact in many/most operations will be much, much faster. It’s also not optional for SSD startup disks: macOS will use APFS by default for those.
There’s a great blog post which shows how to install High Sierra on an internal SSD without converting the startup volume to APFS. I recommend this approach if you are nervous about relying on the new file system.
https://blog.macsales.com/42884-is-it-possible-not-to-convert-to-apfs-when-upgrading-to-high-sierra
I have had nothing but problems with AFPS on the official release of high Sierra. I took a brand new SSD 250Gb drive on the thunderbolt 2 port and did the following:
1 copied a few application to the drive.
2 tried to tun those applications and they failed to launch. Saying that the applications were incomplete.
So I downloaded a game onto the SSD drive and it launched ok. After an update, it to failed to launch with the same error.
Being a former Apple QA manager (retired), this unacceptable because I was able to duplicate the problem easily. Formatting the SSD as HFS
, it did not fail. I am worried about the reliability of AFPS more than the speed.
This is amazing and I have reported it before. Since I can only see the post “Ross the Heretic @ 11:03 am on November 16, 2017” but I know there are more, including mine, I am posting this to let admins know and to see such posts and possible answer to my questions. This is a very serious bug of this forum. I have not seen that elsewhere after decades and thousands of sites.
Could the beta version of SoftRAID used with AFPS have any impact on the results?
The beta version of SoftRAID was only used for the tests on the ThunderBlade, the test which showed the smallest difference between the two file systems.
The tests with SSDs and HDDs were performed by creating volumes with Disk Utility.
Are the features that cause APFS to run more slowly really all that cool? What does the trade off really mean, besides slower copying speeds? We need a more complete description of what copy-on-write and snapshots means. After all, snapshots have been available on Windows for years, though people don’t seem to take advantage of them all that much. Which is why you hear “reinstall” more often than “rollback” with Windows machines.
But what do these features mean to the Mac? If my data really is more secure in APFS, then maybe I don’t need a fancy RAID to protect it. A lot of questions need more complete answers before APFS becomes mandatory on the Mac. Maybe people should hold off on buying that new MacBook Pro until we know more about it.
APFS basically means a more robust filesystem that was written from the ground up, rather than the creaky old HFS+, which was a whole bunch of aging code that had lived long past its time.
APFS will protect the filesystem much better in the case of crashes, power failures, etc, i.e. the kinds of issues that you might normally need DiskWarrior to handle on HFS+. The ability to “freeze” the filesystem at a specific point via snapshots, for testing or backup purposes, is most useful for techies and in enterprise environments.
However, with modern SSDs being so fast to write, the risks of a crash or power failure aren’t as big of a deal as they were with HDDs. And with most people using laptops, power failures are mostly a non-issue.
So for the consumer space, I don’t see APFS as a big benefit over HFS+. For techies, creative professionals (who have tons of data on RAIDs) and enterprise/SMB environments (who also have tons of data on RAIDs), APFS is a fairly welcome change. HFS+ on huge volumes is an accident waiting to happen, whereas APFS is far more robust.
I’m betting that the speed differences will decrease as Apple continues to tune APFS, and although APFS will also be somewhat slower on the same hardware, that speed difference is from protecting your data…even if the risk is small.
APFS does *nothing* to protect you from total device failure, however, so a proper backup, and (if you’re time-sensitive) a RAID to allow you to keep on keeping-on in case of such a failure, still apply.
Thanks for the great article. Does it mean DiskWarrior will not be needed with APFS?
On the other hand, does APFS have some kind of auto-healing feature as ZFS has? Check out:
Self Healing with ZFS
This demo shows how ZFS’s self healing features can repair silent data corruption which occurs in mirrored volumes. This is in contrast to traditional volume managers which won’t notice that the corruption ever occurred. In this demo, we splat random data over one side of a mirror. Please use extreme caution if you decide to replicate this experiment. And don’t try it with a traditional volume manager.
http://students.mimuw.edu.pl/SO/Projekt07-08/temat5-g2/zfs_demos/selfheal.html
APFS does not have the self-healing properties of ZFS. As John said, it also does not protect you from disk failure so you will still have to use a RAID if you want protection from these failures.
If you use a 3 disk mirror (RAID 1), RAID 6 or RAID 6+ volume you can protect yourself from the type of disk data corruption which ZFS protects from.
@Tim Standing, since you brought it up :-) when we will see some RAID6 goodness in SoftRAID? With larger disk sizes, good ol’ RAID5 is a little scary these days….
There is second blog post describes copy on write in detail. It will be posted here in the next day or two.
In other words, we lose speed for gimmicks that aren’t really necessary. Typical Apple: it ain’t broke so we’ll fix it.
I wouldn’t say that. HFS+ was the last filesystem used in modern computers to *not* have those “gimmicks”. Every Windows box has them. Most Linux boxes have them. And APFS speeds up typical operations (like duplicating and copying files to the same device) *a lot*.
A good overview of the benefits of APFS along with some of the drawbacks was done by BackBlaze: check it out.
https://www.backblaze.com/blog/apfs-apple-file-system/
HFS+ is broke and needed fixing.
HFS+ can only handle 4 billion files since it is 32-bit. As hard drives become ever larger you will hit this file limit. APFS has better file security, safety, error correction, and encryption capabilities than HFS+
I recognize that APFS is slower at copying large numbers of files. The performance on a single file is the same as HFS Extended. So for the really speed critical tasks, like editing uncompressed video, APFS should be just as suitable as HFS Extended.
In our testing, it appears to be much harder to get a corrupted volume with APFS than with HFS Extended. I think this is a great change and will benefit a lot of Mac users.
I haven’t necessarily found what you say to be ubitquitous… I.e., please do not generalize, for what you say can be said for Microsoft, Dell, IBM, etc. Also, “typical Apple”- where the hell did you get this??!!??