ACTUALIZACIÓN : La pregunta fue cambiada para centrarse específicamente en cómo crear un disco RAM en Big Sur/Monterey. Puedes hacerlo abriendo el Terminal y ejecutando el siguiente comando:
diskutil erasevolume HFS+ 'ramtmp' `hdiutil attach -nobrowse -nomount ram://8388608`
Esto creará un disco de 4 GB de RAM que estará disponible en /Volumes/ramtmp . Ahora puedes configurar tu compilador para que utilice esa carpeta para los archivos temporales.
Si para usted es importante que sea el /private/tmp que lleva al disco RAM, puedes configurarlo manualmente usando algunos comandos como este:
hdid -nomount ram://8388608
newfs_hfs -v tmp /dev/rdiskX
diskutil mount -mountPoint /private/tmp /dev/diskX
(donde X debe ser sustituida en ambos comandos por el número emitido por el comando hdid)
Todavía dudo mucho que tenga un impacto real en el desgaste de tu SSD a largo plazo.
En los comentarios escribes que te diriges específicamente al caso de uso de "compilación de compiladores y grandes proyectos". Como no has dado más detalles, es difícil saber si te refieres a yacc, SableCC o algún otro compilador, y a qué te refieres exactamente con proyectos grandes.
Sin embargo, cuando uso compiladores, o simplemente en general compilar grandes proyectos utilizando clang o Xcode, no encuentro que /private/tmp es "golpear mucho". Para los proyectos de Xcode me parece más bien que el DerivedData se utiliza mucho la carpeta ( ~/Library/Developer/Xcode/DerivedData/ ). Tiene más sentido poner eso en un disco RAM, no para reducir el desgaste, sino para optimizar el rendimiento. Puedes encontrar programas existentes que facilitan esa parte - incluyendo el montaje automático después del arranque:
https://github.com/ikiapps/Setup-Xcode-Derived-Data-RAM-Disk
RESPUESTA ANTIGUA :
Creo que las alarmas son infundadas. No hay ninguna razón para creer que el uso de las unidades SSD esté aumentando (sea lo que sea que eso signifique) ahora a un ritmo mayor que hace 5 años, por ejemplo, o que esto signifique que los jugadores, usuarios o desarrolladores comunes deban buscar sus propias formas de reducir el desgaste de las unidades SSD.
Por el contrario, con el paso de los años, las unidades SSD se han hecho más grandes y tienen un mejor firmware. Unas unidades SSD de mayor capacidad significan que la nivelación del desgaste es más fácil. Una mayor información del sistema operativo al firmware interno de la SSD también significa que la nivelación del desgaste es más fácil.
Todo esto significa que, aunque el "uso" pueda aumentar, las unidades SSD rara vez son el primer componente de hardware de su componente que falla, y fallar debido a demasiadas escrituras es aún menos probable. Recuerde también que un fallo de este tipo es en realidad uno de los pocos fallos de hardware que tienen pocas repercusiones, es decir, la unidad pasa a ser de "sólo lectura" y a menudo puede copiar los datos a una unidad externa sin perder nada.
Adquirir la cantidad de RAM adecuada para su carga de trabajo específica es siempre una buena idea. Si tienes mucho intercambio de entrada y salida, el rendimiento suele deteriorarse tanto que el sistema se convierte en un lastre a ojos de casi todo el mundo. Esto también desgasta un poco el SSD. En ese caso, lo que realmente quieres es un extra de RAM.
Sin embargo, si sólo se trata de fugas de memoria (como es el caso de muchos), el intercambio se vuelve unilateral y no afecta al rendimiento en la misma medida. También significa que casi no hay desgaste práctico para el SSD.
/private/tmp se utiliza normalmente para archivos temporales de corta duración creados por las aplicaciones, y para pequeños archivos de larga duración creados por demonios, como tuberías con nombre, archivos pid y sockets de dominio unix. En cualquier caso, estos suelen ser de "escritura única, lectura única". Dudo que se consiga una reducción real de tales "escrituras/reescrituras pesadas" para las aplicaciones ordinarias de MacOS (incluso para el desarrollo de software y los juegos) trasladándolas a un disco RAM. En lugar de eso, te arriesgas a que los programas empiecen a fallar si el disco RAM se queda sin espacio. Recuerde también que estos archivos temporales siguen siendo almacenados en la caché del sistema de archivos habitual, por lo que tienen la posibilidad de existir en la RAM, si el sistema operativo así lo decide.
Conseguir que un disco RAM funcione bien en el arranque para este escenario en particular no es realmente tan interesante. Si tienes escrituras pesadas ocurriendo todo el tiempo, los pocos segundos durante el arranque son sólo una gota en el océano - y realmente no importa que el disco RAM sólo se establezca después del arranque.
