How to keep /private/tmp on a RAM drive with Big Sur & Monterrey+?

Solution 1:

UPDATE: The question was changed to focus specifically on how to create a RAM disk on Big Sur/Monterey. You can do that by opening the Terminal and running the following command:

diskutil erasevolume HFS+ 'ramtmp' `hdiutil attach -nobrowse -nomount ram://8388608`

This will create a 4 GB RAM disk that is available on /Volumes/ramtmp. Now you can set your compiler to use that folder for temporary files.

If it is important for you that it must be the /private/tmp path name that leads to the RAM-disk, you can set that up manually using a few commands like this:

hdid -nomount ram://8388608
newfs_hfs -v tmp /dev/rdiskX
diskutil mount -mountPoint /private/tmp /dev/diskX

(where X is to be replaced in both commands by the number output by the hdid command)

I still very much doubt that it will have any real impact on the wear on your SSD in the long run.

In the comments you write that you specifically target the use case of "compiling compilers and large projects". As you haven't given more details, it is difficult to know whether you're talking about yacc, SableCC or some other compiler compiler, and what exactly you mean by large projects.

However when I use compiler compilers, or just in general compile large projects using clang or Xcode, I do not find that /private/tmp is "hit a lot". For Xcode projects I rather find that the DerivedData folder is used a lot (~/Library/Developer/Xcode/DerivedData/). It makes more sense to put that on a RAM-disk, not for the sake of reducing wear, but rather to optimize performance. You can find existing programs that make that part easy - including mounting it automatically after boot:

https://github.com/ikiapps/Setup-Xcode-Derived-Data-RAM-Disk

OLD ANSWER:

I think the alarm bells are unfounded. There's no reason to believe that SSD usage is increasing (whatever that might even mean) now at a higher rate than it was 5 years ago for example - or that this means that ordinary gamers, users or developers should seek their own ways to reduce SSD wear.

On the contrary over the years, SSD drives have become larger and have better firmware. A larger capacity SSD drives means that wear-levelling becomes easier. More information from the operating system to the SSD's internal firmware also means that wear-levelling becomes easier.

All this means that even though "usage" might be increasing, the SSDs are seldom the first hardware component of your component to fail - and failing because of too many writes is even less likely. Remember also that such a failure is actually one of the few hardware failures that have few repercussions - i.e. the drive goes "read-only" and you can often copy the data over to an external drive without losing anything.

Purchasing the amount of RAM suitable for your specific workload is always a good idea. If you have lots of swapping in and out, performance usually deteriorates so much that the system becomes a drag in almost anyone's eyes. This also wears the SSD ever so slightly. In that case, you really want extra RAM.

However, if you're just dealing with memory leaks (like many are), the swapping becomes onesided and does not affect performance to nearly the same degree. It also means that there's almost no practical wear to the SSD.

/private/tmp is usually used for short-lived, temporary files created by applications, and small, long-lived files created by daemons - such as named pipes, pid-files and unix domain sockets. In any case these are usually "write once, read once". I doubt that you would get any real reduction of such "heavy write/rewrites" for ordinary macOS applications (including for software development and gaming) by moving it to a RAM disk. Instead you risk that programs starts failing if the RAM disk runs out of space. Remember also that these temporary files are still being cached by the usual file system cache, so they do have a chance of existing in RAM, if the operating system chooses so.

Getting a RAM disk working right at boot for this particular scenario is actually not that interesting. If you're having heavy writes occurring all the time, the few seconds during boot are only a drop in the ocean - and it doesn't really matter that the RAM disk is only established after booting.