Should You Continue Using HFS+?
The most compelling argument for retaining HFS+ is on rotating hard disks, because APFS can result in severe fragmentation, most importantly in the file system metadata, so causing degraded performance; as SSDs don’t suffer those performance penalties, this could be a good reason for continuing to use HFS+ on hard disks, while switching SSDs to APFS.
That argument may hold good for storage which is in active use, such as boot disks and those containing working files, but appears less compelling in more static use, to contain relatively stable archives or backups in which there is limited turnover of files or data. Although objectively assessing the effects of fragmentation is fraught with difficulty, one basic question is whether there is any difference in performance between the file systems to begin with.
I updated my spinning hard drives to APFS when that became necessary in order to make bootable clones. The other main benefit is that APFS snaphots on the destination are a great way to fit multiple backups onto the same drive. Previously, I used multiple partitions, which is much less space-efficient.
The hidden downside is that, for reasons I don’t understand, most of my APFS backup drives take an unpredictable amount of time to mount. With HFS+ it consistently took a few seconds. With APFS, sometimes it takes a few seconds, but other times it takes 5 minutes or even an hour before I can access the drive’s contents. A few of my APFS backups do have multiple partitions. They mount in a random order. If I’m lucky, the one I need mounts first, and in that case the backup is almost always done before the other partitions have even mounted.
Sometimes, the APFS volume never auto-mounts, but it does show up in Disk Utility where—after it takes 10 minutes to launch—I can manually tell it to mount.
Other times, the APFS volume does auto-mount, using the password stored in the keychain, but it shows a password prompt, anyway. Sometimes, despite trying to dismiss this dialog, it stays on-screen the entire time I’m using the drive. I try to drag it mostly off-screen so that it doesn’t block my other windows.
Sometimes, generally after a kernel panic, APFS volumes don’t even show up in Disk Utility after a restart. I have to power cycle the enclosures. (Ironically, most of the kernel panics that I’ve been getting with my M1 Pro MacBook Pro seem to be related to HFS.)
Previously:
- Time Machine Evolution and APFS
- Which Devices Should You Boot Your M1 Mac From?
- Upgrading to a 14-inch MacBook Pro With a Studio Display
- The Role of Bootable Duplicates in a Modern Backup Strategy
- APFS and Time Machine in Big Sur
- Enabling Defragmentation on APFS Hard Drives
- APFS Enumeration Performance on Rotational Hard Drives
- Poor Mac Performance Without an SSD
8 Comments RSS · Twitter
Uh, I also have this problem, that Volumes mount with a big delay. I thought it was a general BugSir/Monterey problem and never realized that it only happens with APFS devices. The bigger problem is: I have my disk connect to my TB3 dock. When I want to unmount all volumes it sometimes takes 20 minutes. That’s very annoying when I’m in hurry and want to leave the house with my MacBook. It’s safer and most times faster to just shut down my Mac. But I also had situations where it takes minutes. When I unplug the devices in this procedure, the Mac immediatly shuts down. So the slow shutdown also seems to depend on the APFS volumes.
Yep, seeing the mount delays on my Macs, too. I have several Macs where the fast internal SSD is split into multiple partitions, some with HFS and most with APFS containers. And even those can take up to a minute to get mounted.
Also, to repeat my comment on Howard's site:
As the author of a popular file search tool (Find Any File), I also like to point out that searching for file names and other directory properties (modification and creation date, file size), HFS+ is significantly faster than APFS (that's due to two things, one being the more complex file name encoding in APFS and the other being the use of two instead of one B*tree to look up entries in a volume's directory). So, if you plan to have a million files on your volume, searching the entire volume will be much faster on HFS vs. APFS (such as 5s vs. 30s).
And I’m talking about searching without Spotlight here, and with a program like FindAnyFile or EasyFind. OTOH, if you enable Spotlight on the volume, then it should not make a difference performance whether it’s using HFS+ or APFS.
I wonder if this is the case for generic APFS volumes (like you might create for data storage) or if it only affects bootable backups and Time Machine.
I found that bootable backups take a very long time to mount (and to unmount - the process continues for quite some time after the icon is removed from the Finder). I've assumed that it's because there are multiple volumes sharing a volume group (system, data, maybe others).
I suspect Time Machine may be similiar, because the Finder needs to enumerate (and mount?) all the snapshots in order to present them in the GUI.
It would be interesting to see if this happens for other kinds of volumes. I do know that non-bootable backups (of just the Data volume) seem to mount and unmount much more quickly, although still not as fast as my HFS+ volumes did.
Mike Bombich performed testing on APFS formatted rotational drives and found enumeration to suffer. When booting, this is a particular problem:
The other time that the performance difference will be starkly noticeable is when you're booting macOS from a rotational HDD. macOS seeks and stats thousands of files during the startup process, and if that's taking 15 times longer on a rotational disk, then your 30-second startup process is going to turn into 8 minutes. When the system does finally boot, the system and apps will still feel sluggish as all of your applications load, and those applications each stat hundreds of files. The system is still usable, especially as a rescue backup device, but it's not the kind of experience you'd want for a production startup disk nor for a high-stress restore scenario.
Here: https://bombich.com/blog/2019/09/12/analysis-apfs-enumeration-performance-on-rotational-hard-drives
Using APFS on spinning disk will eventually (6-9 months) in experience result is filesystem IO so slow that eventually a system trying to mount it will trigger its deadlock timeout in the kernel and reboot rending the entire filesystem inaccessible. Using it on spinning rust is absolutely a bad idea if you care about your data.
All of this discussion and comments about APFS, including some of the earlier stuff about how it's impossible to clone APFS filesystems properly, makes me think that it just kinda sucks. Sure it might be technically impressive and boast some snazzy new features compared to HFS+, but does APFS actually let anyone do anything *better* than the way things worked before?
The latest version of macOS now has the system in a signed, sealed volume that gets weirdly combined with a data volume, giving the system an additional level of protection from tampering on top of its filed being owned by root and changes prevented by SIP. In reality it introduces extra complexity, larger more error prone system updates, more control over your own system by Apple and less control by users, far less options about how to use and manage it due to it being a rather impenetrable black box, and just generally more bugs. As far as I can tell, it doesn't do anything *better*.
If anyone disagrees or can give me some clear and concrete examples of APFS having a serious advantage, I'm happy to hear about that.
The APFS block allocator is clearly better, yes. But, inevitably, it just isn't optimised at all well for HDDs so metadata locality is poor, and this is very noticeable when you have lots of snapshots.
As to the security theatre in macOS more generally, well I'm already running into an issue where I want to replace the default MTA binaries but I can't do it without breaking the seal because they're under /usr. It's a bloody nuisance. I can't really justify using a version of Postfix that's so far out of date. Really--would it have been so hard to link sendmail, mailq, newaliases to symlinks under /var/select so we can choose suitable replacements? Or just include and use mailwrapper(8)?
> does APFS actually let anyone do anything *better* than the way things worked before?
I imagine it was largely designed to be better _for Apple_.
> larger more error prone system updates
The goal was presumably to make them _less_ error-prone, by essentially atomically replacing an entire binary blob. Another benefit (for Apple, but therefore also indirectly for users) is that it shares far more code with iOS, therefore enjoying more engineering effort.
One would hope Apple has metrics on whether they've achieved that goal. It's always hard to extrapolate from anecdotes whether something has overall become more robust or not.
(No doubt the size of those updates is annoying, though.)
