Dive Into APFS
Tim Standing of OWC gave a great presentation about APFS at the MacSysAdmin conference in Göteborg (via St. Clair Software). Topics include previous Apple file system efforts, the fragmentation caused by copy-on-write, reasons to never use APFS on a spinning hard drive, sluggish performance compared with HFS+, making snapshots with tmutil and restoring them using macOS Recovery, and a mysterious 11th hour change to the format.
His SMART Alec app also looks interesting.
Previously: Local Time Machine Uses APFS Snapshots, APFS Benchmarks.
Update (2017-11-16): Edward Marczak:
Funny timing: you posted this an hour after Tim gave an updated version of this talk at @MacTechConf. There were significant updates in that month.
Update (2017-11-20): Howard Oakley:
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.
Update (2017-11-27): Lloyd Chambers:
Folder copy performance is pathetic: I observed it as about 100 times slower versus my Mac Pro. This same folder took about 3 seconds on my 2013 Mac Pro, with its SSD which is about 1/3 as fast as the blazingly fast SSD in the 2017 iMac 5K. Who at Apple thinks this is a win?
[…]
Bottom line: APFS is a substantial performance downgrade on the fastest SSD that Apple ships, which is the ideal claimed use case for APFS.
6 Comments RSS · Twitter
Most surprising piece from that presentation was that there was a huge change to APFS in beta 9 just a couple of weeks before GM.
Has anyone run latency tests with APFS vs HFS+? I recall the original APFS presentation stating that the goal was to prioritize read latency over raw throughput. That said, having a 100x decrease in throughput is unacceptable.
What bothers me the most is that Apple didn't say anything about the fragmentation problem with copy-on-write and HDDs. One could read between the lines with HDD/Fusion Drives not being automatically converted, but there wasn't any warning or technote... just silence while we had to find all this out for ourselves. By the time these types of performance tests were posted, I had already converted my backup drives to APFS. They're all FileVault-encrypted, so the prospect of erasing, reformatting, backing up again, then booting into each one to enable FileVault, then waiting a week or more for them to finish encrypting... I'm not really feeling up to the task of dealing with that kind of time sink at the moment.
I guess Apple feels it's fine now to ship OS-level code with glaring issues like these? I can only imagine what they found that caused them to remove Fusion Drive support at the 11th hour.
[…] to update to macOS 10.13 High Sierra. And I would consider backup drives to be an exception to the general rule of not using APFS with spinning hard […]
[…] is a shame because HFS+ fragmentation will likely be with us on spinning disks for a long time. I’m also not convinced that APFS fragmentation is a non-issue on SSDs. APFS […]
