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

Question

How do you setup /private/tmp on a RAM drive with Big Sur & Monterrey+?

I will explain some of my concerns here below, but my question is simply that. Apparently some have misunderstood and thought I want an explanation of why it doesn't need to be done, but in my case it does need to be done and I simply want to do this, especially since I operate without SIP enabled.

Reducing wear on solid state drives seems to be more and more important as we see SSD usage increasing. With the newer MacBook Pros (2016 on) and now the much more expensive 2021 MacBook Pros (MacBookPro18,1-4), some of us have alarm bells going off about trying to reduce cache wear when possible.

For example, I believe it is wise to purchase the 64GB models not for the sake of performance, but rather to give the OS and apps more breathing room so that less swapping and hard drive usage occurs.

In this same line of thinking, it seems to me that a 4gb or 8gb or even 16gb RAM drive might be useful to replace /private/tmp and any temporary file usage if one develops software, games or requires frequent and heavy writes/rewrites on the drive.

Memory caching for fs rw is also not often effective in scenarios I've seen.

As you may have noted, I originally asked this as well, but this is secondary to the "how to" and thus I acknowledge having made a mistake of essentially putting two questions into one, but will leave this here since it answers why I got the most highly voted current reply below:

Has anyone put any thought or study into this to see what kind of load it reduces from the storage drive?

And does anyone have a solid method for creating and mounting a RAM drive such that it's in use right at system boot? (eg, we used to be able to put things like this into RC and we could still do so if we are able to mount the root volume RW after disabling SIP it seems.)

Answer 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.