APFS vs HFS+ for Sonoma HDD

What’s the current best idea for external HDD format under Sonoma. Got a new 20TB USB 5 Gb/s external that will be both Time Machine and a clone of my OWC ThunderBay mini. Will only be used under Sonoma. Bombich says that enumerating files is faster under HFS but suggests that mostly APFS is still preferred because of the advantages it brings unless a particular app requires faster file enumeration. In my case the cloning will happen overnight so speed isn’t a big issue ( it will be a CCC clone job)…so I’m tending to choose APFS but wanted to make sure this was best practice.

For some time, my impression has been that for spinners, HFS+ was still preferable, but since I mostly got that impression from Mr. Bombich, maybe it isn’t any longer?

At least for the TM partition, you likely want APFS. Not because HFS+ doesn’t perform well enough on spinning rust, but because TM to APFS (TMA) is so much more advanced than TM to HFS+ (TMH). Corruption has been much less of an issue since TMA was introduced and TM performance too has greatly benefited. As usual, Howard Oakley has delivered excellent detail.

For general-purpose data storage, absolutely yes. APFS has many features that depend on SSD behavior in order to work efficiently. Things like copy-on-write semantics and snapshots tend to result in a lot of file fragmentation. This doesn’t affect SSD performance much (if at all), but it can lead to a lot of head motion on an HDD, which will significantly hurt performance.

HFS+ was designed for HDDs. It tries to allocate data in a way to minimize fragmentation and head motion and should produce better performance, especially after you’re been creating, deleting and modifying files for a long time.

For an extreme example, make a bootable clone to a HDD and then boot it. You’ll find the boot time and overall system performance so slow that it becomes practically useless.

But this isn’t necessarily the case for backup volumes. Backups (especially to APFS destination when using APFS-aware tools like CCC and Time Machine) have usage semantics that are different from general-purpose storage.

In the backup scenario, you aren’t randomly writing/modifying/deleting files. You are writing many GB of data sequentially (for the initial backup). Then the backup software makes a snapshot, so your updates after that append to that data without modifying or deleting any of it.

Yes, some data gets freed as snapshots expire (e.g. the hourly snapshots expire when they’re 24 hours old and the daily snapshots expire after two weeks), but even with that, the data doesn’t get nearly as fragmented as it would for general-purpose file access.

Combined with the fact that you usually don’t require very high performance (you’re only copying what changed since the last backup, not everything), APFS’s HDD-disadvantages are not a very big problem.

It may also be tricky to set up a new TMH (TM over HFS) volume. Any remotely modern version of macOS will create the volume as APFS if you just click through the Time Machine control panel to add a destination volume.

I think (but never tried it) you can use the command-line tmutil command to create a TMH volume. From the manual page

$ man tmutil

TMUTIL(8)                         System Manager's Manual                        TMUTIL(8)

     tmutil - Time Machine utility

     tmutil verb [options]
     Each verb is listed with its description and individual arguments.

     setdestination [-ap] arg
             Configure a local HFS+ or APFS volume, AFP share, or SMB share as a backup
             destination. Requires root and Full Disk Access privileges.

             When the -a option is provided, arg will be added to the list of
             destinations. Time Machine will automatically choose a backup destination
             from the list when performing backups. When the -a option is not provided,
             the current list of destinations will be replaced by arg.

             If you wish to set an HFS+ or APFS volume as the backup destination, arg
             should be the mount point of the volume in question. When setting an AFP or
             SMB destination arg takes the form:


             In the AFP and SMB cases, the password component of the URL is optional; you
             may instead specify the -p option to enter the password at a non-echoing
             interactive prompt. This is of particular interest to the security-conscious,
             as all arguments provided to a program are visible by all users on the system
             via the ps tool.

So, in theory, I think you can:

  • Format an empty volume as HFS+. (For this example, named “MyTM”)
  • sudo tmutil setdestination -a /Volimes/MyTM

But that having been said, I agree with @simon. TMA (TM over APFS) works just fine (or at least “good enough”) on HDDs. If you don’t have an explicit need for TMH (perhaps because you want older Macs to be able to read the volume), then why bother?

“[W]e do not recommend using APFS on volumes containing HDDs unless you are using the volume for a Time Machine backup.”

1 Like

I have an OWC Mercury Elite Pro Dual mini USB-C enclosure. For the past 5 years it’s been the target drive for CCC clones from a Mojave web server. It had two Samsung 2.5" SSDs, set up as independent disks, formatted as HFS+, and has performed flawlessly.

We shut down this machine and installed new, 2TB Crucial drives into the Elite Pro, as independent drives and formatted as APFS. We attached it to a new Mac Mini running Sonoma and file sharing. We set up clones using CCC and it reliably crashed EVERY time the clones ran. CCC reported an error that the drives disconnected but they had actually hung - the drives froze and had to be unplugged. This happened every day for a week.

In frustration I brought the drives home and reformatted them as HFS+. It has been perfectly reliable ever since. I’m clearly not an expert on file systems but at this stage I can say there is NOTHING that appeals to me about APFS. It appears buggy, unreliable and I am very, very concerned about the machines I have which are forced to run it.

Whilst it’s clearly the future, I would never run it by choice.

1 Like

I’m clearly not an expert on file systems but at this stage I can say there is NOTHING that appeals to me about APFS. It appears buggy, unreliable and I am very, very concerned about the machines I have which are forced to run it.

Whilst it’s clearly the future, I would never run it by choice.

You are not alone. I can’t think of a single thing I like about it. The sole purpose seems to be to keep users from mucking up their system software, which makes things easier for Apple’s techs and support people. But it makes some things more difficult for the user. If I had named the OS versions after Mojave, they would be Folsom, Alcatraz, San Quentin, Ironwood, and Pelican Bay.

Starting with Big Sur, they also have bad aesthetics.

With High Sierra and Mojave, you can still run them on HFS+ volumes, with some extra work.

1 Like

So after you reformatted the drives as HFS+, you put them back in the exact same scenario with enclosure, the Mac mini, and Carbon Copy Cloner and had no problems? Or did other variables change as well? I’ve seen problems with putting new drives in old enclosures in the past.

Personally, I’ve never had any trouble with APFS, but I’m using SSDs entirely now for all but archival storage.

Same here, although I don’t have the same setup as @trilo. As @alanterra and @Shamino discuss, my 1TB HDD in an OWC USB-3 Mercury Elite Pro enclosure is formatted as APFS as my Time Machine backup disk. My other two external SSDs (one in a OWC Envoy Express TB3 enclosure, one in a Orico USB-C enclosure) are formatted APFS. All work like a champ. The SSD in the OWC enclosure is where I have several Xcode projects, so it gets hammered when I set off builds through XCode. .

My extra USB HDDs that I use for general puttering around get formatted for HFS+.

Did you ever bounce this by OWC to see if they could pinpoint what the issue is? At the worst if this is an Apple bug, it needs to get reported and fixed.

Correct, the only thing which changed was the formatting. Same machine, same enclosure, even the same CCC task (obviously changing the target drive to the newly formatted version).

So far hasn’t missed a beat (touch wood).

Obviously not worth messing with a working system, but I’d be intrigued to figure out what the other key variables are. Obviously, APFS works in general because millions of people are using it. So I wonder if there might be some sort of interaction with the enclosure, or those particular drives. But the only way to tell would be to reformat them as APFS again and see if the problem recurred, and then try those drives in another enclosure, etc. Way more work than it’s worth. :slight_smile:

I was somewhat suspicious of the new drives but as they’re (still) working flawlessly I think that can be dismissed.

What I can’t test easily is the enclosure itself. It was purchased around 2017 - before APFS was widely available and was consequently running HFS+. It’s possible it doesn’t have the ‘smarts’ to run APFS - maybe a new one would be fine…

I hit that back in the day when I’d get a new big drive and try to put it in an old drive enclosure only to discover it couldn’t handle terabyte-sized drives, or something like that. This discussion supports that.


Perhaps someone else knows more about the variable associated with the controller cards in drive enclosures, which would give us a sense of how enclosure compatibility can wane over time.

I do see that there are some chipset conflicts with some enclosure controller cards and Apple silicon Macs. So, getting new enclosures might be the better part of valor when moving to an M-series Mac.


1 Like

I actually wrote about that 10 years ago:

TL/DR: There are multiple protocols for accessing storage devices, and these protocols have different size limits. The capabilities of the bridge chip are going to determine the size limits.

The ugly details:

  • SATA uses 48-bit block addresses. So if every block is 512 bytes (the most common size), that limits any SATA device to 248 blocks or 131,072 TiB. A limit we’re not likely to hit any time soon.

  • Older PATA/IDE drives had an older protocol with only 28-bit block addresses. These devices would be limited to 228 blocks, or 128 GiB. You may remember dealing with this limit if you’ve been using computers for a long time.

  • Before ATA’s LBA (logical block address) system, PATA/IDE drives used a 22-bit system for block addresses, where bit-fields corresponded to cylinder/head/sector numbers (aka CHS). Originally corresponding to a drive’s physical organization, later drives had translation circuitry in order to exceed the limits of these field sizes. For an effective size limit of 222 blocks or 2 GiB. You may remember this being a limit in the past.

  • And before ATA/IDE, there were other limits, mostly due to the maximum number of cylinders/heads/sectors a motherboard’s configuration supported.

    • Some motherboards topped out at 1024 cylinders, 256 heads and 63 sectors (and MS-DOS also had a limit of 256 heads), limiting drives to about 8 GiB.
    • Some older motherboards limited configuration to 1024 cylinders, 16 heads and 63 sectors for a 504 MiB limit

Of course, in the Mac world, this was less of an issue, because Macs traditionally used SCSI drives, not IDE. And when Apple started using IDE, support for 48-bit blocks was common.

But SCSI has its own set of limits. There are three different sizes for all SCSI block-access commands:

  • One uses 21-bit addresses, which results in a 1GiB limit
  • One uses 32-bit addresses, which results in a 2 TiB limit
  • The latest uses 64-bit addresses, which results in an 8 ZiB (8 giga-terabytes)

But as far a I know, SCSI host adapters never imposed limits like this, so old controllers can support new drives as long as the operating system’s device driver has support.

But these SCSI size limits come to bite back when USB enclosures are used, because USB’s mass storage spec is based on the “SCSI transparent command set”, and newer USB enclosures use USB-attached SCSI protocol (UASP).

If an enclosure’s bridge chip only implements the 32-bit address commands, then it won’t be able to access a drive larger than 2 TiB, even though the SATA/NVMe interface has no such limit. Amazingly, many enclosures sold today still don’t include support for 64-bit addresses, even though storage devices larger than 2 TiB are commonplace today.

Which, ultimately, means you can’t just put any drive in any enclosure. You need to read the detailed specs for any enclosure to make sure it is documented to support the capacity of your drive. And if you can’t get those specs, it may not be safe to assume compatibility with a drive larger than 2 TiB.


I also recall being caught with the 2TB limit on some enclosures although it seems like a looong time ago. I just remoted into the server and the backups haven’t missed a beat with HFS+. As they’re simple data backups I’m going to leave well enough alone.

Just as an aside, coming to you today from Central Australia where it’s a balmy 39°C… Walked 10k around Uluru and then a nice dip in the resort pool. Apologies for those currently suffering freezing winters.