Input and output have long been key factors in computer performance, and capable of bringing everything to a crawl unless carefully managed. This is most obvious when foreground and background processes contend for common resources such as disk storage. A popular solution has been to impose delays on I/O performed for intensive background tasks, like backing up, so giving more important tasks preferential access to I/O. This policy is known as I/O throttling, and has come to determine hardware choice.

For example, folk wisdom is that there’s little point in wasting a faster drive to store your Time Machine backups, because when those backups are made, their write speed is throttled by macOS.

I/O Throttling

Documentation of I/O policy is in the man page for the getiopolicy_np() call in the Standard C Library, last revised in 2019, and prevailing settings are in sysctl’s debug.lowpri_throttle_* values. Those draw a distinction between I/O to local disks, being “I/O sent to the media without going through a network”, such as I/O “to internal and external hard drives, optical media in internal and external drives, flash drives, floppy disks, ram disks, and mounted disk images which reside on these media”, and those to “remote volumes” “that require network activity to complete the operation”. The latter are “currently only supported for remote volumes mounted by SMB or AFP.”

Inclusion of remote volumes is a relatively recent change, as in the previous version of this man page from 2006, they were explicitly excluded as “remote volumes mounted through networks (AFP, SMB, NFS, etc) or disk images residing on remote volumes.”

Five policy levels are supported for IOPOL_TYPE_DISK:

• IOPOL_IMPORTANT, the default, where I/O is critical to system responsiveness.
• IOPOL_STANDARD, which may be delayed slightly to allow IOPOL_IMPORTANT to complete quickly, and presumably referred to in sysctl as Tier 1.
• IOPOL_UTILITY, for brief background threads that may be throttled to prevent impact on higher policy levels, in Tier 2.
• IOPOL_THROTTLE, for “long-running I/O intensive background work, such as backups, search indexing, or file synchronization”, that will be throttled to prevent impact on higher policy levels, in Tier 3.
• IOPOL_PASSIVE, for mounting files from disk images, and the like, intended more for server situations so that lower policy levels aren’t slowed by them.

However, the idea that throttled I/O is intentionally slowed at all times isn’t supported by the explanation of how throttling works: “If a throttleable request occurs within a small time window of a request of higher priority, the thread that issued the throttleable I/O is forced to a sleep for a short period. This slows down the thread that issues the throttleable I/O so that higher-priority I/Os can complete with low-latency and receive a greater share of the disk bandwidth.”

Settings in sysctl for Tier 3 give the window duration as 500 milliseconds, and the sleep period as 200 ms, except for SSDs, whose sleep period is considerably shorter at just 25 ms. Those also set a maximum size for I/O at 131,072 bytes. You can view those settings in the debug section of Mints’ sysctl viewer.

Some years ago it was discovered that the user can globally disable IOPOL_THROTTLE and presumably all other IOPOL_TYPE_DISK policy with the command
sudo sysctl debug.lowpri_throttle_enabled=0
although that doesn’t persist across restarts, and isn’t documented in the man page for sysctl. This is provided in an option in St. Clair Software’s App Tamer, to “Accelerate Time Machine backups”, for those who’d rather avoid the command line.

Apple silicon Macs

Since the man page for getiopolicy_np() was last revised, Apple silicon Macs have changed I/O. Most is now handled in some way through specialised Arm cores within the chip, and CPU cores come in two (now three) types, Efficiency and Performance (and Super in the M5 family). Background threads such as those performing the work associated with IOPOL_THROTTLE are now most likely to be running on Efficiency (or M5 Performance) CPU cores.

If you wanted to do away with all throttling, you not only have to change the debug.lowpri_throttle_enabled setting, but you’d need to move those background threads to run them on Performance (M5 Super) CPU cores, which isn’t possible unless you have control over the code. There is evidence that macOS may do this anyway when performing the first full Time Machine backup, which achieves significantly faster speeds than subsequent incremental backups.

Dangers

The big disadvantage of completely disabling I/O throttling policy is this can only be applied globally, so including I/O for Spotlight indexing, file synchronisation, and other background tasks, as well as those needing high-priority access to I/O. Leaving the policy disabled in normal circumstances could readily lead to adverse side-effects, allowing Spotlight indexing threads to swamp important user storage access, for example.

Conclusions

Even when Macs were simpler and all CPU cores were the same, disabling I/O throttling was at best experimental, and ran the risk of compromising higher priority I/O. In Apple silicon Macs, relocating threads from E to P cores isn’t possible, except when running them in a virtual machine. Without that, there seems little if any benefit from disabling I/O throttling. However, the claim that there’s no performance benefit to be obtained from faster backup storage media is demonstrably false. Perhaps it’s time to return I/O throttling to the obscurity it deserves.

We don’t always notice something is wrong within a few hours of the event that caused a problem. Sometimes it can take days or weeks before we realise that we need to check something in the log. By that time all trace has vanished, as the active log will have rolled those log entries long before we go looking for them. This article shows how to recover and analyse events from the more distant past, using a Time Machine backup and my free utilities LogUI and Logistician. My target is the macOS 26.3 Tahoe update installed on my Mac mini M4 Pro on 11 February, and I performed this analysis 11 days later, on 22 February.

When was the event?

In this case I remember updating at around 18:30-19:30 on 11 February, but I don’t even need to recall the date. I first copied the logdata.statistics.1.jsonl file from my active log in /var/db/diagnostics to a working folder in ~/Documents, then opened it using Logistician.

The log file listing between 18:10:39 and 19:26:47 on 11 February 2026 shows a remarkably rapid turnover of log files that’s an obvious marker of that update. Highlighted here is a Persist file that’s exceptionally large at 139 MB of log entries for a collection period of just 37 seconds, although like other tracev3 log files in the Persist folder that only takes 10.5 MB of disk space.

Retrieve the log

Although I’m confident those logs were removed many days ago, I open LogUI, then select its Diagnostics Tool from the Window menu. I click the Get Info tool and select my active log in /var/db/diagnostics. That tells me that the oldest log entry there dates from 17 February, so there’s no point in trying to find those entries in that log.

Like all good backup utilities, Time Machine also backs up the whole of the log folders, and I can use those to create a logarchive file for analysis. I therefore locate the next backup made after those log entries were written, on 12 February, and copy the /var/db/diagnostics and /var/db/uuidtext folders into a new folder in my working folder, ready to turn them into a logarchive.

In LogUI, I open its Logarchive Tool from the Window menu and use that to turn those folders into a logarchive I can access using LogUI. I check that freshly created logarchive using the Catalogue tool to confirm that it contains the log files I want to browse.

Identify the event

With the historical log safely preserved in a logarchive and a defined time of interest, my next task is to identify the event I want to investigate. In this case, I could probably go straight ahead and look at all entries for a few seconds, but in other circumstances you may need to know which entries to look for.

Back in Logistician, I select that extraordinary Persist log file and view it in a Chart. Most of the other log files over this period look like this:

with large quantities of entries from softwareupdated, com.apple.MobileSoftwareUpdate and similar processes. But the huge Persist file that filled in only 37 seconds is exceptional.

Almost all its entries are from audiomxd, and all other entries are dwarfed by its size.

Browse the event

By default when you click on LogUI’s Get Log tool it will fetch those log entries from the active log. To switch that source to my logarchive file, I click on the Use Logarchive tool and select the logarchive I just created in my Documents folder. To remind me that it’s no longer looking in the active log, that window then displays a red-letter caution of !! Logarchive to the left of the Start control. That also reminds me to use dates and times within the range covered by that logarchive.

I set the Start to ten seconds into the collection period of that large Persist file, a period of 1 second, and the maximum number of entries to 100,000, then click on the Get Log tool.

This is one of the most remarkable log extracts I have ever seen: in this 1 second period, the audiomxd process in com.apple.coremedia wrote about 53,000 entries to the log. Over the 37 seconds of log records in that single Persist file, audiomxd must have written at least 1.5 million log entries. These are all apparently the result of the ‘death’ of the AudioAccessory service audioaccessoryd, and its recovery after updating macOS.

Summary

1. Identify approximate time of event from /var/db/diagnostics/logdata.statistics.1.jsonl using Logistician.
2. Check in LogUI whether that falls within the period of the active log.
3. If not, retrieve /var/db/diagnostics and /var/db/uuidtext from the next backup made after the event.
4. Convert those folders into a logarchive using LogUI’s Logarchive tool, and check it contains the period of the event.
5. Identify the processes involved using Logistician’s chart.
6. Set LogUI to use that logarchive, enter the correct date and time, and get log entries for the required processes.

Despite rumours that Time Capsules had lost support in macOS Tahoe, those still backing up to them have discovered they continue to work, at least to existing backup stores. I’m very grateful to Michael for telling me that Tahoe no longer lets you start a new backup on a Time Capsule, nor it appears to any other store requiring HFS+ (Mac Extended) format.

Time Capsule support is expected to end with macOS 26 Tahoe, as macOS 27 is unlikely to support AFP any more, so those Intel Macs compatible with Tahoe can continue backing up to Time Capsules until they’re replaced. Apple remains intentionally vague about this, stating only that AFP “won’t be supported in a future version of macOS”, and has been even less clear about support for backup stores on HFS+.

Apple’s documentation implies that has been dropped already. Since Big Sur, it has stated: “APFS or APFS Encrypted disks are the preferred format for a Time Machine backup disk. If you select a new backup disk that’s not already formatted as an APFS disk, you get the option to erase and reformat it. If the disk is a Mac OS Extended format disk that contains an existing Time Machine backup, you aren’t asked to erase and reformat the disk.” However, “Time Machine still supports backups on Mac OS Extended format (Journalled), Mac OS Extended (Case-sensitive, Journalled), and Xsan formatted disks.”

Other support documents are even less helpful. This one doesn’t even mention HFS+, while another, dated 5 December 2025 and detailing backup disks you can use with Time Machine, concentrates on AFP and implies that HFS+ remains fully supported on Time Capsules.

Unfortunately, in macOS Tahoe, the moment you erase your Time Capsule to start a fresh backup series, Time Machine considers that’s a new backup disk, and wants it to be in APFS format. As that’s not possible, it refuses, stating “Time Machine can only be used if it contains existing Time Machine backups for this Mac.”

Michael found an ingenious workaround on his MacBook Air M2, by installing Sequoia in its own container, starting up from that, and then creating the new backup store on his Time Capsule. When he restarted his Mac in Tahoe, Time Machine was perfectly happy to start a new backup set, as it already existed.

From this we can only conclude that macOS Tahoe:

• fully supports Time Machine backups using AFP,
• fully supports Time Machine backups to Time Capsules with backup stores already formatted in HFS+,
• but refuses to create a new backup store on a Time Capsule,
• also refuses to create a new backup store on local storage formatted in HFS+, but insists on reformatting that to APFS.

I don’t believe for a moment this behaviour is a bug, but is an intentional limitation that Apple hasn’t documented. While I have been warning since July 2021 that you should replace any Time Capsules, as they won’t be supported for much longer, this abrupt change is unwarranted.

If you’ve upgraded to macOS Tahoe and erase your Time Capsule’s backups, you’ll be unable to store any new backups on it, unless you revert to Sequoia. This is yet another compelling reason not to upgrade to macOS 26.

In last week’s Explainer on snapshots, I stated that “you can safely remove all Time Machine snapshots from that volume except the most recent, which is also the smallest.” This article explains the reasoning behind that.

Why delete snapshots?

Time Machine and other backup utilities make local snapshots on the volumes they back up in addition to copying all changes to backup storage, normally on a different device like an external disk. Because of that, local snapshots are a bonus not a backup. When a volume being backed up is running short of free space, one good method of freeing up space is therefore to delete some of those local snapshots.

Sometimes deleting just one snapshot can free up a lot of space, but estimating the amount likely to be returned is complicated, and to a degree not always readily predictable. If you know one of those snapshots has retained a very large file like a VM or macOS update, you may be able to get away with just deleting the single snapshot, but it’s more usual to need to delete as many as possible, typically just keeping one.

If you are going to retain one snapshot, then by far the smallest is likely to be the most recent, as that almost invariably contains the fewest changes from the current contents of the volume. The oldest snapshot is almost certain to contain much greater changes, so deleting it normally returns the greatest free space. So in terms of meeting your goal of freeing up space, the best strategy is to delete all snapshots except the most recent.

Why keep snapshots?

Although a bonus, a local snapshot is valuable if something goes wrong with a volume and its backup isn’t readily available, either because it’s in a different location or there’s a problem with backup storage. In those circumstances you’re most likely to want that snapshot to be the most recent made, rather than the oldest. So in terms of justifying the retention of any snapshot, the best strategy is to retain the most recent.

What does Time Machine use snapshots for?

Before APFS, Time Machine made the closest it could come to snapshots in HFS+ only when it was unable to perform a scheduled backup. That typically happened on Macs remote from their backup storage, and was intended as the best possible substitute for a proper backup. When Apple introduced APFS in macOS High Sierra, it explicitly stated how its snapshot feature would spare Time Machine from having to run its own code to imitate that.

In High Sierra and Mojave, Time Machine relied on snapshots to determine what needed to be backed up from an APFS volume. It made a snapshot at the start of each backup, and compared that with the snapshot made with the previous backup, a process known as snapshot diffing, and used those differences to determine what should be backed up. That relies on keeping the snapshot made at the time of the last backup; if that’s unavailable, Time Machine has to use another method, and in many cases ends up backing up a lot more than is necessary.

One major disadvantage of snapshot diffing is that it requires the snapshot made for the last backup to be retained until the next backup can be made. When backups are made regularly every hour, that was acceptable, but a Mac that couldn’t back up for several days could end up with an old snapshot occupying tens of GB. Since macOS Catalina Time Machine has therefore been relying on an older method, introduced with HFS+, using the FSEvents database maintained on each volume. That doesn’t require snapshots at all.

Currently, Time Machine will therefore use FSEvents to determine what needs to be backed up from each volume, but there are occasions when that isn’t possible, for example when that database becomes damaged. If that happens, and the snapshot made at the time of the last backup is available, then Time Machine may decide to use snapshot diffing. If that’s not possible, it may fall back to performing a much larger backup than is necessary.

To enable snapshot diffing to take place if needed, Macs that make regular hourly backups should retain their most recent local snapshot.

That becomes complicated and unpredictable in the case of Macs that may skip regular backups, so some snapshots match backups but others don’t. This is confounded by the rule applied for automatic deletion of local snapshots when they are more than 24 hours old, unless that snapshot is the last on that volume. Without matching each snapshot to its backup (or lack of backup), you can’t know which might need to be retained in case Time Machine needs to use snapshot diffing to determine what should be backed up in the future. Whatever you decide to do, if you delete any local snapshots there’s a risk that might result in the next backup being larger than necessary. But the chances are that Time Machine will still be able to use FSEvents rather than snapshot diffing.

Other backup utilities

Time Machine appears to be the only backup utility that can use snapshot diffing to determine what should be backed up. You should therefore be able to delete local snapshots made by other backup utilities without any penalty. If in any doubt, consult their documentation.

Conclusion

If you need to delete local snapshots to free up space in a volume, you can safely delete all except the most recent snapshot, when each snapshot is accompanied by a backup. Where some backups may have been skipped, that is still likely to prove the best overall strategy.

Snapshots are a simple concept that only becomes complex when you dig into the detail. One of the fundamental features introduced in APFS, they are now used extensively, to form the System volume for all versions of macOS since Big Sur, and in many backup systems including Time Machine.

As the name implies, a snapshot is a preserved copy of a volume at a moment in time. Creating one is both simple and lightning quick: APFS makes a copy of the file system metadata for that volume, and retains with it all the data of its files. From then on, the working copy of the file system metadata changes as files are modified, created and deleted. But all the original file data at the time the snapshot was made is retained. That enables you to roll back the live volume to the exact state it was in when the snapshot was made. The snapshot itself (its file system metadata) is kept in the same container as the live volume, and their file data overlaps.

Snapshots rely on another fundamental feature of APFS, a scheme called copy on write. When a file is changed, the data for that file isn’t changed in place in the same storage blocks, but written out to new blocks. This enables the snapshot to retain all the original data for its files, while the live volume consists of a mixture of old unchanged data, and replacements for those blocks that have changed since the snapshot was made.

Size

This leads to the biggest disadvantage of snapshots: when first made, the only additional storage space they require is for their copy of the file system metadata, which is relatively small. Over time, though, as more data blocks are changed in the live volume, the size of the data the snapshot must retain grows, and can after a few weeks become enormous, depending on how active the file system is in that volume. What was initially measured in MB quickly becomes GB, and if you forget about that snapshot, it will become hundreds of GB in size.

Management

While some operating systems allow users to create their own snapshots and maintain them, macOS doesn’t: apps that have the restricted entitlement to create snapshots are required by Apple to maintain them as well. That’s why apps that make snapshots are backup utilities, and are required to have a mechanism for automatically deleting their old snapshots to prevent them overwhelming storage.

Creating a snapshot is almost instantaneous, but deleting one is more complex and time-consuming. This is because the file system has to identify all the old retained data blocks that are no longer required, and allow them to be freed up for re-use. When that’s performed across the millions of files that could be in the snapshot’s file system metadata, it will inevitably take time. It’s also not entirely predictable, particularly when there may be multiple snapshots for that volume.

APFS snapshots are always of whole volumes, although some file systems can make snapshots of directory trees within a volume. Unlike Time Machine’s backup exclusions, each snapshot it makes of a volume it’s backing up contains every file in that volume. If you have large database or VM files, although Time Machine and other backup utilities can exclude them from taking up space in their backups, they can’t exclude them from their snapshots. If you do want to keep such large files, it’s usually better to put them in a volume that doesn’t get snapshots made of it.

Snapshots are also read-only, and once one is made, it can’t be changed. This is beneficial, as it ensures nothing can change the old files and their data. However, it also means that if something goes wrong in a snapshot and it starts throwing errors, you effectively can’t repair it. At present, you also can’t copy a snapshot, which makes it impossible to make a copy of your Time Machine backup storage, as that’s composed of snapshots.

Purposes

Your Mac uses snapshots in three ways:

• local snapshots, typically made by Time Machine and its equivalents on the volumes they back up. Time Machine only keeps those for 24 hours before automatically deleting them for you, although third-party utilities are usually more flexible. You can normally access these, or roll back to them, by mounting the snapshot as a volume.
• backup snapshots, only created by Time Machine and used to store each backup on your Mac’s backup storage. These are created during the backup process by assembling a copy of the local snapshot together with its changed data into a synthetic snapshot, which is how Time Machine makes its backups now.
• the Signed System Volume, created during installation and updating of macOS on the System volume of your boot volume group. This is a snapshot of that System volume, and is mounted and used as the macOS system. Unlike all other snapshots, this has a tree of cryptographic hashes added to it, to verify and seal the SSV. If a single bit is changed in that snapshot, then that change propagates to the top of the tree, macOS will detect it, and invalidate that SSV.

Utilities

In addition to features provided by third-party backup utilities, you can manage snapshots using Disk Utility. Open its View menu and first enable Show All Devices, then Show APFS Snapshots. Select the Data or Macintosh HD – Data volume in the left of the window, and you’ll see a list of all APFS snapshots for that volume, together with an indication of the size of each.

To delete a snapshot in Disk Utility’s list, select it and use the Delete… command from the contextual menu (Control-click). Be careful, though, as there’s no undo. You can safely remove all Time Machine snapshots from that volume except the most recent, which is also the smallest. That latest snapshot is needed when that volume is next backed up by Time Machine. If you remove that too, then the next backup could be a full backup of everything on that Data volume, something best avoided if possible.

If anyone claims they have engineered something so you can set it and forget it, remind them of the third step in that process, where you come to regret it. Without attentive monitoring, any system is likely to fail without your being aware. Time Machine is a good example, and this article illustrates how it can fail almost totally without you being aware that anything has changed.

Scenario

I’ve recently been testing a security product on my Mac mini M4 Pro. One of its more novel features is device control similar to Apple’s Accessory Security for Apple silicon Mac laptops. I’m sure I’m not the only person who has wondered why that feature hasn’t been incorporated into desktop models, and here is a third-party developer doing just that and more. For their implementation lets you specify precisely which peripherals can be connected, down to the serial number of each SSD.

When I installed and went through the onboarding of this product, I naturally assumed that my Time Machine backup storage, an external SSD, would be allowed by this control, as it was connected at the time. At that time I was offered no option to manually allow it, and as its three volumes remained listed in the Finder’s Locations I didn’t check its settings.

When I started that Mac up the following day, I discovered that I had lost access to that external SSD. Its three volumes were still there in the Finder, but any attempt to open them failed with an error. I quickly disabled the device control feature, just in time to allow Time Machine to make its first hourly backup since 12:35 the previous day, just after I had installed the security software. Time Machine had happily gone that long without backing up or warning me that it had no backup storage.

Compare that with what would have happened with any other backup utility, such as Carbon Copy Cloner, which would have informed me of the error in terms loud and clear. I think this results from Time Machine’s set and forget trait, and its widespread use by laptop Macs that are often disconnected from their backup storage. Thankfully I hadn’t come to regret it, this time.

Evidence

Not only does Time Machine not draw the attention of the user to this error, but it can be hard to discover from the log. Run T2M2, for example, and the evidence is subtle:
Times taken for each auto backup were 4.3, 0.5, 0.6, 10.5, 2.5, 0.8, 0.9, 0.7, 0.6 minutes,
intervals between the start of each auto backup were 86.6, 29.3, 1197.7, 55.5, 60.3, 60.1, 60.1, 60.3 minutes.
(Emphasis added.)

A gap of almost 20 hours between backups far exceeds the nine hours it was shut down overnight. But at the end, T2M2 reports
No error messages found.

I know from the security software’s log that it had blocked access to the backup storage after Time Machine had completed the last of its hourly backups at around 12:35. This is what the next attempt to back up reported:
13:23:54.382 Failed to find any mounted disk matching volume UUIDs: {("A3A3DADA-D88E-499B-8175-CC826E0E3DE4")}
13:23:54.382 Skipping scheduled Time Machine backup: No destinations are potentially available
13:23:54.487 attrVolumeWithMountPoint 'file:///Volumes/VMbackups/' failed, error: Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"
13:23:54.488 attrVolumeWithMountPoint 'file:///Volumes/OWCenvoyProSX2tb/' failed, error: Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"
13:23:54.489 attrVolumeWithMountPoint 'file:///Volumes/Backups%20of%20MacStudio%20(7)/' failed, error: Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"
13:23:59.103 attrVolumeWithMountPoint 'file:///Volumes/VMbackups/' failed, error: Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"
13:23:59.104 attrVolumeWithMountPoint 'file:///Volumes/OWCenvoyProSX2tb/' failed, error: Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"
13:23:59.104 attrVolumeWithMountPoint 'file:///Volumes/Backups%20of%20MacStudio%20(7)/' failed, error: Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"

Time Machine then fell back to what it has long been intended to do in such circumstances, making a local snapshot of the volume it should have backed up. This starts with a full sync of buffers to disk storage,
13:23:59.876 FULLFSYNC succeeded for '/System/Volumes/Data'
in preparation for that snapshot
13:24:00.024 Created Time Machine local snapshot with name 'com.apple.TimeMachine.2026-01-12-132359.local' on disk '/System/Volumes/Data'

These were repeated at 14:24:06.638, and hourly thereafter until the Mac was shut down. Accompanying those few entries were tens of thousands of errors from APFS and Time Machine.

The only clue as to the cause was a single log entry
14:24:06.805543 EndpointSecurity ES_AUTH_RESULT_DENY: event 1
in which Endpoint Security is logging the event that access to the external device was denied.

Lesson

If you do just set it and forget it, you will come to regret it. Attentive monitoring is essential, and when anything does go wrong, don’t pass over it in silence.