☰

Разметка разделов для SSD + 3 HDD

tag-icon • tag-icon linux ubuntu hard-drive partitioning ssd
Разметка разделов для SSD + 3 HDD

Вчера я получил новую рабочую станцию, оснащенную:

  • 120 ГБ - OCZ Vertex3 MAX IOPS
  • 300 ГБ — Western Digital Velociraptor (10 тыс. об/мин, среднее время поиска около 4 мс)
  • 2x2 ТБ Samsung Ecogreen F4

Система будет работать под управлением Ubuntu с основной целью разработки большого количества Java. Иногда мне приходится разрабатывать Java в виртуальной машине Windows; для этого мне нужны быстрые виртуальные машины. Я много читал об износе SSD, и, возможно, размещать рабочее пространство Eclipse на SSD — плохая идея, из-за всех небольших записей, которые делают сборки. Возможно, рабочее пространство (и, следовательно, /home) может найти лучшее место на Velociraptor, который действительно быстрый.

Как мне разбить все это на разделы, чтобы получить от этого максимум? Я открыт для любых предложений. LVM тоже может быть вариантом. Может быть, размещение третьего раздела на SSD для одного образа VirtualBox было бы хорошей идеей.

В настоящее время я думаю:

  • SSD: 2 ГБ /boot, осталось место для /
  • Велоцираптор: LVM охватывает весь диск.
    • 150 ГБ /домой
    • Оставшееся место для /virtualMachines или что-то в этом роде
  • Диски Samsung (LVM для обоих или по одной группе томов для каждого? - Последнее будет лучше с точки зрения безопасности данных, поскольку если один диск в большой группе томов выйдет из строя, все будет потеряно)
    • Разделы для данных, архива и т.д.

решение1

Есть еще один вариант, если вас интересуют надежность, выравнивание износа и разница между скоростью записи и скоростью чтения:

у меня естьКарточка 9010RAM-диск с батарейным питанием, с которого я запускаю Linux. Его заполнение обойдется дороже, чем стоимость среднего SSD, но вы получите некоторые преимущества:

  • Быстрая скорость чтения И быстрая скорость записи. SSD имеют действительно высокую скорость чтения и несколько менее высокую скорость записи.
  • Выравнивание износа не требуется.
  • Нет проблем с тем, что заполненные диски записываются медленнее, чем пустые, как это бывает с SSD.
  • Внутренняя батарея компенсирует перебои в подаче электроэнергии примерно в течение дня, а для питания RAM-привода можно использовать внешний сетевой адаптер (в дополнение к внутренней резервной батарее).
  • Проблема хранения данных дольше срока службы батареи решается с помощью встроенной в устройство SD-карты: после отключения питания и падения напряжения батареи до определенного низкого уровня RAM-Drive выполняет резервное копирование содержимого памяти на компактную флэш-карту объемом 64 ГБ, встроенную в переднюю часть RAM-диска, а затем при включении питания копирует данные SD-карты обратно в RAM-память RAM-диска.

Чтобы ответить непосредственно на часть вопроса, как организовать разделы на SSD (или RAM-диске):

Я поместил все, кроме /homeRAM-диска. /homeидет на жесткий диск. Для Slackware64 требуется около 5 ГБ, поэтому из 32 ГБ RAM-диска у меня есть много дополнительного места для разработки.

Вам не обязательно выполнять свою работу в /home, хотя это обычный "способ Linux", вместо этого подумайте о создании каталога в дереве Linux, например /javaили /projects, который будет на вашем RAM-диске, настройте разрешения и владельца, чтобы ваш пользователь мог использовать этот каталог и размещать ваши проекты на SSD/RAM-диске для скорости. Поместите вашу ОС/инструменты/исходный код на RAM-диск, работайте там, а затем создайте скрипт выключения, который копирует вашу ежедневную работу на жесткий диск.

В качестве меры безопасности я написал пару простых скриптов, которые создают резервные копии важных пользовательских файлов, которые находятся на RAM-диске (или SSD) на случай возникновения проблем. Такие файлы, как ваш /etc/fstabи /etc/X11/xorg.confкоторые могут быть хлопотными, чтобы получить точные данныебыстро(особенно если у вас есть куча mp3-плееров в fstab или сложная настройка монитора в xorg.conf и т. д. в этих файлах), если у вас возникли проблемы с SSD/RAM, которые в какой-то момент начали путаться.

У меня также есть пара скриптов, которые делают резервную копию/восстанавливают каждый отдельный файл на RAM-диске в каталог на жестком диске, просто на всякий случай. Я упоминаю эти скрипты, потому что в другом ответе упоминались проблемы надежности SSD (или RAM-дисков). Скрипты дают мне дополнительную меру резервного копирования и простого восстановления, если что-то пойдет не так в какой-то момент. Настройте хроническое задание для резервного копирования несколько раз в день, в любом случае это неплохая идея.

Итак, что я делаю:

  • /на SSD
  • /work( /javaили /projectsили другое) для вашего рабочего места, на SSD
  • /homeна жестком диске
  • /usr/scripts(создано для пользовательских скриптов)
  • скрипты для резервного копирования файлов конфигурации пользователя с SSD на жесткий диск
  • скрипты для полного копирования RAM-диска на жесткий диск.

Согласно их веб-сайту, время доступа к RAM-диску составляет 0,01 мс. Это намного быстрее, чем у HD, но не вдвое (как кто-то сказал ранее).

решение2

SSD не так надежен, как HDD, лучше использовать его как временные/страницы/скретч-файлы, а не как загрузочные. Поскольку у вас Velociraptor, SSD не нужен.

В офисе я использую SSD в качестве основного диска и разрабатываю приложения C# на Windows XP, Visual Studio быстро компилирует и запускает для отладки моих проектов. Я также использую SSD в среде Hyper-V в качестве файлов подкачки/свопа/временных файлов, чтобы дать жесткому диску передохнуть. Если вам нужна более высокая производительность, используйтеeBoostrкэширование наиболее часто используемых файлов, а также снижение использования жесткого диска, особенно на веб-сервере.

Связанный контент