Fast SSDs aren’t always fast when writing to them. Even an Apple silicon Mac’s internal SSD can slow alarmingly in the wrong circumstances, as some have recently been keen to demonstrate. This article explains why an expensive SSD normally capable of better than 2.5 GB/s write speed might disappoint, and what you can do to avoid that.

In normal use, there are three potential causes of reduced write speed in an otherwise healthy SSD:

• thermal throttling,
• SLC write cache depletion,
• the need for Trimming and/or housekeeping.

Each of those should only affect write speed, leaving read speed unaffected.

Thermal throttling

Writing data to an SSD generates heat, and writing a lot can cause it to heat up significantly. Internal temperature is monitored by the firmware in the SSD, and when that rises sufficiently, writing to it will be throttled back to a lower speed to stabilise temperature. Some SSDs have proved particularly prone to thermal throttling, among them older versions of the Samsung X5, one of the first full-speed Thunderbolt 3 SSDs.

In testing, thermal throttling can be hard to distinguish from SLC write cache depletion, although thorough tests should reveal its dependence on temperature rather than the mere quantity of data written.

The only solution to thermal throttling is adequate cooling of the SSD. Internal SSDs in Macs with active cooling using fans shouldn’t heat up sufficiently to throttle, provided their air ducts are kept free and they’re used in normal ambient temperatures. Well-designed external enclosures should ensure sufficient cooling using deep fins, although active cooling using small fans remains more controversial.

SLC write cache

To achieve their high storage density, almost all consumer-grade SSDs store multiple bits in each of their memory cells, and most recent products store three in Triple-Level Cell or TLC. Writing all three bits to a single cell takes longer than it would to write them to separate cells, so most TLC SSDs compensate by using caches. Almost all feature a smaller static cache of up to 16 GB, used when writing small amounts of data, and a more substantial dynamic cache borrowed from main storage cells by writing single bits to them as if they were SLC (single-level cell) rather than TLC.

This SLC write cache becomes important when writing large amounts of data to the SSD, as the size of the SLC write cache then determines overall performance. In practice, its size ranges from around 2.5% of total SSD capacity to over 10%. This can’t be measured directly, but can be inferred from measuring speed when writing more data than can be contained in the cache. As it can’t be emptied during full-speed write, once the dynamic cache is full, write speed suddenly falls; for example a Thunderbolt 5 SSD with full-speed write of 5.5 GB/s might fall to 1.4 GB/s when its SLC write cache is full. This is seen in both external and internal SSDs.

To understand the importance of SLC write cache in determining performance, take this real-world example:

• 100 GB is written to a Thunderbolt 5 SSD with an SLC write cache of 50 GB. Although the first half of the 100 GB is written at 5.5 GB/s, the remaining 50 GB is written at 1.4 GB/s because the cache is full. Total time for the whole write is then 44.8 seconds.
• Performing the same to a USB4 SSD with an SLC write cache in excess of 100 GB has a slower maximum rate of 3.7 GB/s, but that’s sustained for the whole 100 GB, which then takes only 27 seconds, 60% of the time of the ‘faster’ SSD.

To predict the effect of SLC write cache size on write performance, you therefore need to know cache size, out-of-cache write speed, and the time required to empty a full cache between writes. I have looked at these on two different SSDs: a recent 2 TB model with a Thunderbolt 5 interface, and a self-assembled USB4 OWC 1M2 enclosure containing a Samsung 990 Pro 2 TB SSD. Other enclosures and SSDs will differ, of course.

The TB5 SSD has a 50 GB SLC write cache, as declared by the vendor and confirmed by testing. With that cache available, write speed is 5.5 GB/s over a TB5 interface, but falls to 1.4 GB/s once the cache is full. It then takes 4 minutes for the cache to be emptied and made available for re-use, allowing write speeds to reach 5.5 GB/s again.

The USB4 SSD has an SLC write cache in excess of 212 GB, as demonstrated by writing a total of 212 GB at its full interface speed of 3.7 GB/s. As the underlying performance of that SSD is claimed to exceed that required to support TB5, putting that SSD in a TB5 enclosure should enable it to comfortably outperform the other SSD.

Two further factors could affect SLC write cache: partitioning and free space.

When you partition a hard disk, that affects the physical layout of data on the disk, a feature sometimes used to ensure that data only uses the outer tracks where reads and writes are fastest. That doesn’t work for SSDs, where the firmware manages storage use, and won’t normally segregate partitions physically. That ensures partitioning into APFS containers doesn’t affect SLC write cache, either in terms of size or performance.

Free space can be extremely important, though. SLC write cache can only use storage that’s not already in use, and if necessary has been erased ready to be re-used. If the SSD only has 100 GB free, then that can’t all be used for cache, so limiting the size that’s available. This is another good reason for the performance of SSDs to suffer when they have little free space available.

Ultimately, to attain high write speeds through SLC write cache, you have to understand the limits of that cache and to work within them. One potential method for effectively doubling the size of that cache might be to use two SSDs in RAID-0, although that opens further questions.

Trim and housekeeping

In principle, Trim appears simple. For example, Wikipedia states: “The TRIM command enables an operating system to notify the SSD of pages which no longer contain valid data. For a file deletion operation, the operating system will mark the file’s sectors as free for new data, then send a TRIM command to the SSD.” A similar explanation is given by vendors like Seagate: “SSD TRIM is a command that optimizes SSDs by informing them which data blocks are no longer in use and can be wiped. When files are deleted, the operating system sends a TRIM command, marking these blocks as free for reuse.”

This rapidly becomes more complicated, though. For a start, the TRIM command for SATA doesn’t exist for NVMe, used by faster SSDs, where its closest substitute is DEALLOCATE. Neither is normally reported in the macOS log, although APFS does report its initial Trim when mounting an SSD. That’s reported for each container, not volume.

What we do know from often bitter experience is that some SSDs progressively slow down with use, a phenomenon most commonly (perhaps only?) seen with SATA drives connected over USB. Those also don’t get an initial Trim by APFS when they’re mounted.

It’s almost impossible to assess whether time required for Trim and housekeeping is likely to have any adverse effect on SSD write speed, provided that sufficient free disk space is maintained to support full-speed writing to the SLC write cache. Neither does there appear to be any need for a container to be remounted to trigger any Trim or housekeeping required to erase deleted storage ready for re-use, provided that macOS considers that SSD supports Trimming.

Getting best write performance from an SSD

• Avoid thermal throttling by keeping the SSD’s temperature controlled. For internal SSDs that needs active cooling by fans; for external SSDs that needs good enclosure design with cooling fins or possibly a fan.
• Keep ample free space on the SSD so the whole of its SLC write cache can be used.
• Limit continuous writes to within the SSD’s SLC write cache size, then allow sufficient time for the cache to empty before writing any more.
• It may be faster to use an SSD with a larger SLC write cache over a slower interface, than one with a smaller cache over a faster interface.
• Avoid SATA SSDs.

I’m grateful to Barry for raising these issues.

Although it may not seem that winter is drawing to a close, Spring isn’t that far away, and now is the best time to start planning your Spring cleaning. That’s an opportunity to give your Mac a good physical clean, and to catch up on software housekeeping as outlined in this article. Ideally you should spend a little time each month or so doing the housekeeping on your Mac. Although it’s usually a rewarding investment of your time, it’s often neglected. If you can’t follow the little-and-often principle, at least set aside some time once a year.

Housekeeping can tackle different types of maintenance, among them

• cleaning up after old apps
• tidying up working folders such as ~/Documents
• archiving and cleaning up emails and Messages
• maintaining media libraries including those of Photos
• checking for orphaned snapshots
• checking System Settings.

If you prefer, you can leave most of those to a paid-for housekeeping utility, but most of those now require a substantial subscription, and placing your trust in them. As I’d never choose to invite someone in to tidy through my personal papers and possessions and discard any they think I don’t need, you might want to consider whether you’d trust software to do the same task with your files and data. While I might not be as thorough as a housekeeping app, I’m responsible for making my own errors.

Clean up old apps

If you don’t remove many old apps from your Mac, this shouldn’t involve much work. If, like me, you have a large library migrated from old Macs and regularly try out new apps, then they can leave significant amounts of junk. The more obvious locations to check in both the top-level Library folder and that in your Home folder include Application Support and Preferences. Don’t forget disused and unnecessary logs in ~/Library/Logs. Any that haven’t been modified for the last year or so should be disposable, and any from apps you no longer use can also be cleared away. There’s more detail here.

Almost all App Store apps and many others now run in their own sandbox, and macOS creates for them a container folder stored in ~/Library/Containers. These are a complex hybrid of real and symlinked folders and files that form the contents of the app’s sandbox. In some cases they may contain documents and other files of more lasting value, so you shouldn’t remove or tamper with them unless you’re sure you know what you’re doing. Similar containers in ~/Library/Daemon Containers are for helper services, while those in Group Folders are shared across apps. There’s more detail here. Containers and Daemon Containers are protected in Sonoma and later, and Group Containers are in Sequoia.

You’ll find further discussion of cleaning up from apps here, and old preference settings here.

Tidy up working folders

Finding and removing duplicate files has long been one of the mainstays of Mac housekeeping. Not only did they waste space on the disk they were stored on, but they wasted it again when they were backed up. The activity has even won its own name: deduplication. Since APFS came to Macs, that has changed. One of its more subtle features is the clone file, making deduplication at best questionable, if not a waste of time and effort.

Unlike hard links, clone files are separate files, with their own inodes, but when first created they share the same data. If you then make changes to either the original or the copy, only the changed data is saved. The more changes are made to a clone, the more new data blocks it uses, until eventually all its data could be different, and the two files each occupy their own space, equal to the sum of the sizes of those two files.

Clone files can only exist in the same volume, though. Copy one of them to another volume, and the whole file is copied. Clone files don’t take any additional space in a snapshot, and Time Machine backups should recognise cloned files, and only back up one set of data for them. So not only do clone files not waste any space on their volume, but they don’t waste any in backups either. This is explained in more detail here.

You’re better off spending your time organising your working documents and other files more efficiently than trying to deduplicate in APFS. When you want to identify which files are occupying the most space on disk, DaisyDisk from the App Store is justly popular.

Archive and clean up emails and Messages

Many of us have accumulated thousands of old messages in our email clients, such as Apple’s Mail. While we don’t want to lose access to those old emails, we don’t do anything to archive them properly and get them out of the way of our active emails. All good email clients, even Mail, support the archiving of old messages to keep them for reference and get them out of our current Inboxes and Sent mailboxes. There are also apps dedicated to doing this, including Moth Software’s Mail Archiver X.

The Messages app is more of a problem, although for most it’s usually a matter of removing old movies, images and other large attachments. macOS, iOS and iPadOS provide useful aids to identifying the largest and removing them without having to trawl though hundreds of old messages. In macOS, open the Storage section of General in System Settings, and click on the Info button for Messages. Although Storage isn’t often an accurate measure of space used on disk, for which you should rely on Disk Utility, its individual tools can be useful.

Archiving the contents of data shared in iCloud is more complex, and explored here.

Maintain media libraries

Although duplicate files may not be worth pursuing in APFS, you are more likely to come across duplicates that can be removed from media libraries, particularly those used by Photos. Recent versions have a Duplicates feature in Photos’ Utilities collection that offers to merge what seem to be identical images to save space and make your library more efficient. There are also third-party apps that claim to do that even better.

Check for orphaned snapshots

All apps that make snapshots are supposed to remove them automatically, in the case of Time Machine after 24 hours. Sometimes, usually because of a minor error in them, one or more snapshots escapes this. Left for more than another day or two, its size will steadily increase until it could occupy the whole of that container.

Checking old snapshots is quick and simple in Disk Utility. If you haven’t already enabled their display, select the Show APFS Snapshots item in its View menu. Then select each of the mounted volumes in turn, and the main window will list all the snapshots on that volume. If any are older than intended, you can select them and use the contextual menu from Control-click to delete them. Don’t try deleting any on the volume Time Machine uses to store its backups, though, as snapshots there are its backups and should be maintained by Time Machine.

Check System Settings

When you’re doing your housekeeping you should also take the opportunity to check through some of System Settings to ensure they’re up to date. This applies particularly to Privacy & Security, and General > Login Items & Extensions.

Privacy & Security allows apps to access protected data, from Calendars to Reminders, or features that could be abused, from the camera to audio recording. One of the more important is Full Disk Access, where you’ll see strange entries, typically including XProtect, which you didn’t add and doesn’t need full disk access anyway. Don’t forget to check through those apps given access to Location Services in the top section.

Login Items & Extensions controls which apps and their services are opened automatically when you log in, and among other things puts some of them into the right side of the menu bar. Background items are other services that run in the background, but can be difficult to identify. Extensions are a varied collection of tools that do anything from adding to contextual menus to augmenting Quick Look or Spotlight. To see which are enabled, you need to click the Info symbol for each.

Summary

• Clean up after removing old apps in Application Support, Preferences and ~/Library/Logs.
• Tidy up working folders such as ~/Documents, but it’s probably not worth deduplicating.
• Archive and clean up emails and Messages, in the latter removing old videos and images through Storage settings.
• Maintain media libraries including those of Photos, where you should check for duplicates.
• Check for orphaned snapshots using Disk Utility.
• Check through System Settings, in Privacy & Security and Login Items & Extensions.

Good housekeeping isn’t about freeing up disk space, it’s about making your Mac more efficient in use.

Several of my most popular apps make use of the main system log in macOS, and I occasionally get questions from those who can’t get them to work properly because their Mac’s log files have mysteriously disappeared. This has puzzled me for the last few years, but I think I’ve discovered the cause: some apps delete those log files in a misguided attempt to clean up your Mac and save storage space. This article explains why you shouldn’t do that.

Which logs?

In theory, since macOS Sierra introduced the macOS Unified log, there should be only one log, and one folder containing its log files, hidden away in /var/db/diagnostics.

In practice, many apps and even parts of macOS ignore those and write their own log files. Those can appear almost anywhere, but popular locations include:

• ~/Library/Logs, the worst offender;
• /Library/Logs, which should be better maintained;
• /var/log, normally properly maintained;
• /var/logs, small and properly maintained.

Those locations contain a mixture of ephemeral information of little value, and some potentially important records, such as the outcome of all volume checks made by fsck on APFS and HFS+ volumes. If your Mac was migrated from a previous model, that may well have copied across logs going back years, and those four folders could well contain dozens of files, and consume several GB of space on your Mac’s startup disk.

What maintains them?

While the Unified log has a dedicated service, logd, that is constantly maintaining the files in /var/db/diagnostics, there’s no app or service that maintains all the others. As they’re considered to be custom features outside the control of the main log, it’s up to the apps that write them to remove old entries when they’re no longer required. Routine system housekeeping used to be performed at regular intervals, run by periodic scripts, but even those have been removed from macOS Sequoia, and before that much of the responsibility still rested with apps that create their own logs.

Logs in /var/log and /var/logs should be well maintained, but for most of logs written outside the Unified log, the answer is that apps responsible for maintaining their own logs don’t, and leave it to the user to clean up after them. Neither do those apps warn the user that they write their own logs but don’t maintain them.

Unified log

Look down through the list of active processes in Activity Monitor and you’ll see two, logd and logd_helper, that are always present from shortly after a Mac starts up until it shuts down. Unlike traditional Unix logs, the Unified log is maintained so its size remains fairly constant, with the main folder of log files, Persist, taking up a little more than 500 MB, and the whole of /var/db/diagnostics coming to about 1.5 GB.

logd does this by working through all the individual entries in the log files and removing those that have passed their retention time. It thus preserves more important entries for longer, and prevents the logs from growing uncontrollably. The unfortunate side-effect of this is that Macs that are making copious log entries have logs that don’t go back long in time. At its worst, that might mean that they may only last a few hours before logd removes them.

Although the Console app provides limited features for accessing your Mac’s log, and the great majority don’t want to go near it, the Unified log has important contents. Among those are reports by Time Machine on its recent backups, and those from XProtect Remediator on its scans to detect and remove malware. It’s also the place where all significant errors and failures should be recorded. Remove the main log files and those all disappear. Apple also may ask for and use recent log records when investigating problems you report to Apple Support or, for developers, using Feedback. Even though you may not want to browse the log yourself, it’s important and not a feature you should throw away.

Housekeeping

Spending a little time every month or so doing the housekeeping on your Mac is an excellent and rewarding investment of your time. When I do this, I like to preserve those logs that might still be significant, including the inevitably copious files written by Adobe’s multitude of services, and anything that still appears to be active. But those that haven’t been modified for the last year or so should be disposable, and any from apps I no longer use can be cleared away without fear. However, I never interfere with the Unified log in /var/db/diagnostics as I know that logd cares for that constantly, and much better than I can.

I’m well aware that many feel that they can delegate the responsibility of housekeeping to an app, now typically one they pay a substantial subscription for. Just as I wouldn’t pay someone to come and work through all my personal papers and records, destroying those that they thought I didn’t need, I will never use an app that does the same with my Macs. If the housekeeping app you use deletes log files, particularly if those could include those of the Unified log, then I’d consider that to be malicious, and proof that the app’s developers don’t understand how macOS works.

And that’s why some discover that those vital logs have been destroyed, and they can’t run the checks built into several of my apps, including the records of XProtect Remediator’s security scans.

Recommendations

• Users: perform housekeeping as a routine, particularly on disused and unnecessary logs in ~/Library/Logs. Never interfere with logs stored in /var/db/diagnostics.
• Developers: avoid writing your own logs. If your software really has to, ensure that it performs its own housekeeping, and inform the user in its documentation.
• Apple: if the Unified log can’t be unified, improve it and make it fit for purpose.