How to improve battery life, performance, and SSD longevity by disabling Unix compliance just a tiny bit

Unix has all kinds of pessimizations that seemed really cool in the 1970s when they were introduced. One of them is ATime.

Unix filesystems often have 3 timestamps associated with a file: Modified time, Accessed time, and Creation (or sometimes Changed) time (affectionately knows as MACTimes). These are discussed to various forms of imprecision all over the place, so be sure to read up if you’re curious.

Anyway, the important one here is ATime, or access time. Technically, every time a file is “accessed” (read(2), open(2)ed, stat(2)ed, among other things), its ATime is supposed to be updated. On modern graphical operating systems, seemingly innocuous things like opening a folder (via a save dialog, even) or performing a search may lead to access times being bumped. Incessant logging also bumps ATimes.

In the opposite corner, we have SSDs, or Solid State Disks, also known as Flash Drives. Most of this story will deal with them, but the optimization here also applies to HDDs (Hard Disk Drives), just to a lesser extent.

SSDs, and flash in general, have some interesting properties. Flash can be read piecemeal in small chunks, and there’s no physical read/write head that needs to move around (hence the “Solid State” portion of the name), leading to their outstandingly high IOPS (Input/Outputs Per Second) compared to their mechanically moving analogs. But writing to them is something of an unmitigated disaster - it takes a really long time, and due to some physical design quirks it can also require read-modify-write style cycles that erase large blocks. They also have a limited number of writes before they’re no longer able to reliably hold data (in fact, most modern drives are constantly failing, and are only saved by aggressive error correction running under the hood. This is similar for HDDs, where each sector is actually much larger than 4KiB, with the extra being Reed-Solomon codes for error correction and some other metadata). SSDs routinely shuffle data around to “wear level” (prevent a single block from being destroyed by lots of writes) and freshen up data (power-off data retention is something of a concern as well). As drives wear, the amount of time data can safely sit in a block shrinks, and wear leveling must kick in more frequently. The various bookkeeping and migration tasks are sometimes called “garbage collection.”

So, all told, minimizing writes to an SSD reduces the odds of a large, power-hungry read-modify-write cycle, and reduces the odds of a garbage collection cycle being kicked off. This seems at odds with ATime though, where writes happen relentlessly.

Fortunately for us, there’s an option to disable ATime updates, called noatime, and we can set or clear it on a mounted volume with a simple command.

sudo mount -vuo noatime /

This will change our root volume to noatime. You can repeat this for other mounted volumes. It’s reset after each reboot, so if something bad happens, just reboot and you’re back to normal. You can also manually unset it if you’re feeling motivated.

$ mount
/dev/disk2s1 on / (apfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
/dev/disk2s4 on /private/var/vm (apfs, local, journaled, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)

to

$ mount
/dev/disk2s1 on / (apfs, local, journaled, noatime)
devfs on /dev (devfs, local, nobrowse)
/dev/disk2s4 on /private/var/vm (apfs, local, journaled, noatime, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)

Disabling ATime means a few features won’t work. There are a few Unix utilities that rely on ATime (some versions of PINE, I’m told). Also, the “Last Opened Time” column in Finder won’t behave properly. But if you can live with those limitations, this can be a easy way to reduce wear and tear on your machine. For HDDs, the performance benefit can be even higher, as there are fewer seeks to write the likely-never-read data.