Существует другой вариант, если надежность, выравнивание износа и разница между скоростью записи и скоростью чтения имеют значение:
У меня есть дисковод ОЗУ Acard 9010 с батарейным питанием, с которого я запускаю Linux. Заполнение будет стоить дороже, чем средний SSD, но вы получите некоторые преимущества:
- Быстрая скорость чтения И быстрая скорость записи. SSD имеют действительно высокую скорость чтения и несколько меньшую скорость записи.
- Нет выравнивания износа не требуется.
- Не беспокойтесь о том, что полные диски пишутся медленнее, чем пустые, как на SSD
- Вспышки питания покрываются внутренней батареей в течение приблизительно одного дня, и вы также можете использовать внешнюю настенную бородавку для питания оперативной памяти (в дополнение к внутренней резервной батарее).
- Дольше, чем время автономной работы, хранение ваших данных решается встроенной в устройство SD-картой: после отключения питания и снижения напряжения батареи до определенного низкого уровня, RAM-Drive выполняет резервное копирование содержимого памяти на компактную флеш-память объемом 64 ГБ. Плата, встроенная в переднюю часть флэш-накопителя, затем при включении питания копирует данные с SD-карты обратно в плунжер оперативной памяти.
Чтобы напрямую ответить на часть вопроса, как расположить разделы на SSD (или RAM-диске):
Я положил все, кроме /home на оперативной памяти. /home идет на жесткий диск. Для Slackware64 требуется около 5 ГБ, поэтому из 32 ГБ ОЗУ у меня много дополнительного пространства для разработки.
Вам не нужно выполнять свою работу в /home , хотя это обычный "путь linux", вместо этого подумайте о создании каталога в дереве Linux, такого как /java или /projects который был бы на вашем оперативном диске, установке разрешений и владении так что ваш пользователь сможет использовать этот каталог и поместить ваши проекты на SSD/RAM диск для скорости. Поместите вашу OS/tools/ исходный код на RAM-диск, поработайте там, а затем запустите скрипт выключения, который копирует вашу ежедневную работу на жесткий диск.
В качестве меры пояса и подтяжки я написал пару простых сценариев, которые создают резервные копии важных пользовательских файлов, которые находятся на диске RAM (или SSD) в случае возникновения проблем. Файлы , как ваш / и /etc/fstab и /etc/X11/xorg.conf , которые могут быть хлопотно , чтобы получить именно право быстро (особенно если у вас есть куча mp3 - плееров в Fstab, или сложной настройки монитора в xorg.conf и т.д. в этих файлах), если у вас возникли проблемы с шифрованием SSD / RAM в любой момент.
У меня также есть пара сценариев, которые на всякий случай выполняют резервное копирование / восстановление каждого отдельного файла на оперативной памяти в каталог на жестком диске. Я упоминаю об этих сценариях, потому что в другом ответе упоминались проблемы с надежностью SSD (или RAM-дисков). Сценарии дают мне дополнительную меру резервного копирования и легкого восстановления на случай, если что-то пойдет не так. Если хотите, настраивайте хронологическое задание для резервного копирования несколько раз в день. В любом случае, это неплохая идея.
Итак, что я делаю:
/ на SSD/work (/java или /projects или другое) для вашей рабочей области, на SSD/home на жестком диске/usr/scripts (созданный для пользовательских скриптов)- скрипты для резервного копирования пользовательских конфигурационных файлов с SSD на жесткий диск
- скрипты для полного копирования ОЗУ на жесткий диск.
ОЗУ имеет время доступа 0,01 мс согласно их веб-сайту. Это намного быстрее, чем HD, но не в два раза (как кто-то сказал ранее).
