Меню Рубрики

Установка debian на ssd hdd

Установка debian на ssd hdd

Настройка диска ssd в ubuntu в связке с hdd

Хочу поделиться опытом настройки диска ssd в Ubuntu. А также развеять мифы оптимизации. К тому же расскажу о монтировании дополнительного диска hdd, чтобы хранить большие объемы информации.

На свой ноутбук купил ssd диск, к тому же вместо оптического привода вставил hdd диск на 500 гигабайт, чтобы хранить фильмы, музыку, фотки.

1. Выравнивание диска ssd.

Итак, хотелось бы сказать про то, что на многих сайтах советуют выравнивать диски ssd. Хочу вас уверить, что и fdisk и gparted и стандартный менеджер разбивки дисков при установке ubuntu автоматически выравнивают разделы.

Вот таким образом я разбил свой диск ssd:

Для корневого раздела «/» выделил стандартно 40 гигабайт.
Для «swap» 4 гигабайта. (swap это хорошее дело на ssd, дальше опишу почему)
Для «/home» домашнего каталога — все остальное.

( Первый раздел это 200 мегабайт — загрузочный раздел для uefi.
В следующей статье расскажу как легко и просто поставить ubuntu на uefi )

Так вот, проверяется диск на выравнивание выполнением следующей команды в консоле: sudo parted /dev/sda align-check opt 1
Если будет выдано следующее сообщение:

«aligned», то значит ваш диск выравнен.
И не надо читать кучу форумов об этом, сидеть с калькулятором и вымерять, все делается автоматически, при использовании популярных программ, таких как gparted, gdisk, fdisk или менеджер дисков установщика.

2. Swap раздел нужен на ssd.

40:1 чтение:запись.
Поэтому не нужно объяснять, что чтение с ssd диска будет идти быстрее, чем с hdd.
Единственное, что нужно сделать, это изменить параметр swappiness на значение 10 . О том, как это можно сделать, написано в этой моей статье:

3. Настройка Trim.

О том, что такое Trim , можно почитать на википедии.
Скажу лишь, что это команда, которая посылает контроллеру информацию о том, где уже были удалены файлы и освобождено место, чтобы очистить информацию на диске.

Если TRIM не работает, накопитель узнает об удалении файла только в тот момент, когда ОС прикажет ему перезаписать LBA, покрывающий ставший ненужным файл.

Вся суть сводится к тому, чтобы включить это.
Для начала нужно проверить, поддерживает ли ваш ssd Trim , делается это выполнение следующей команды в терминале: sudo hdparm -I /dev/sda | grep «TRIM supported»
Если в результате будет сообщение «Trim supported»:

То можно перейти к самой настройке включения.

Можно запускать в ручную командой: sudo fstrim / -v
Выполнение может занять какое-то время, в случае успешности операции, вы увидите следующее сообщение:

То значит Trim был успешно выполнить.

Автоматическое включение можно настроить добавление discard в опции монтирования fstab, об этом расскажу ниже. ( Но многие говорят, что это плохой способ )
Либо создав задачу в Cron (менеджере задач по расписанию):
Создаем ежедневную задачу с именем «trim» следующей командой: sudo gedit /etc/cron.daily/trim
И в открывшийся текстовый файл вставляем следущее:

После чего, сохраняем и закрываем.
Теперь сделаем данный файл исполняемым следующей командой: sudo chmod +x /etc/cron.daily/trim
Теперь ubuntu будет каждый день выполнять trim.
Не советую добавлять параметр discard в опции монтирования fstab.

Стоит упомянуть, что Trim в linux работает только со следующими файловыми системами: ext4 и btrfs.

4. Монтирование разделов в fstab.
При загрузке системы, у вас монтируются диски и разделы, которые указаны в файле:

В принципе, если у вас один жесткий диск ssd, то можете смело им пользоваться без тех настроек, что описаны в данном пункте.
Я в данном файле примонтировал второй жесткий диск, для того, чтобы примонтировать каталоги Музыка, Видео и Изображения, которые будут весить много места и на sdd они все не поместятся.
Ну и еще можно переместить на hdd с ssd каталог /var, так как в него пишется очень много всякого, например логи и деб пакеты перед установкой программ.

Отредактируем данный файл, выполнив следующую команду в терминале: sudo gedit /etc/fstab
Откроется текстовый файл, где перечислены монтируемые устройства:
У меня он вот такой (кликните по изображению для увеличения):

UU /diskette ext4 defaults 0 2

Разберем данную команду подробнее.
1 параметр. Это UUID устройства. Увидеть его можно либо в gparted щелкнув по разделу дважды мышкой. Либо выполнив в терминале команду: blkid
И появится весь список устройств с UUID:

Мне нужен выделенный раздел жесткого диска, в этой строчке выделяем наш UUID и прописываем в первом параметре .

2 параметр. Это точка монтирования.
Это папка, через которую будет производиться обращение к разделу. В принципе, может быть любой.
Прежде чем монтировать в какую-либо папку, не забудьте ее создать.
Например в моем случае это sudo mkdir /diskette

3 параметр. Это файловая система. Думаю объяснения не нужно, если не уверены как пишется или не знаете, то для ленивых есть параметр «auto».

4 параметр. Это параметры монтирования. В принципе достаточно defaults.
Вот какие параметры можно использовать:
exec — Разрешение на запуск исполняемых файлов. Опция включена по-умолчанию.
noexec — Запрет на запуск исполняемых файлов.
auto — Раздел будет автоматически монтироваться при загрузке системы. По-умолчанию.
noauto — Раздел не будет автоматически монтироваться при загрузке системы.
ro — Монтирование только для чтения.
rw — Монтирование для чтения и записи. По-умолчанию.
user — Разрешение простым пользователям монтировать/демонтировать этот раздел.
nouser — Запрещает простым пользователям монтировать/демонтировать этот раздел. По-умолчанию.
defaults — Использование всех параметров по-умолчанию.
discard — Включает Trim на раздела с ФС ext4 и btrfs (очень не рекомендуется)

Читайте также:  Установка газоанализаторов довзрывных концентраций

5 параметр. Флаг бэкапа.
Если 1 — то программа dump включит этот раздел при резервном копировании.
Если 0 — то этот раздел не будет включен при резервном копировании.

6 параметр. Порядок проверки разделов.
Устанавливает порядок проверки раздела при монтировании на наличие ошибок. Если установить один и тот же порядок для двух разделов, они будут проверяться одновременно.
Если 0 — раздел не проверяется.

Таким вот образом можно примонтировать новый жесткий диск к определенному каталогу в систему.

Но если мы выставили параметр монтирования defaults, то на данном жестком диске мы не сможем выполнять операции создания и удаления.
Для этого нам нужно получить права на новый диск, делается это очень просто, выполняем в терминале команду: sudo chmod -R 777 /diskette/
естественно в команде вместо /diskette/ вы указываете свою точку монтирования.

И теперь, когда мы примонтировали жесткий диск, мы можем перегрузиться и проверить что он монтируется.
Теперь вот можно перейти к самому интересному. А именно к монтированию каталогов. Переносу Музыка, Видео, Загрузки на HDD, потому что на нем намного больше места.
Почему не перенести всю папку home?
Потому что в ней хранятся файлы конфигураций и многое другое, высокая скорость чтения которых обязательна. Иначе зачем вообще покупать ssd?

Монтируются каталоги следующим способом.
В каталоге точки монтирования, у меня это /diskette/ создаем каталоги с такими же названиями Музыка, Видео и тд
После чего прописываем следующую команду:

/diskette/Музыка /home/edward/Музыка none bind 0 0

Разберем данный случай для монтирования каталогов,
первым параметром мы указываем нашу новую папку на HDD, которая монтируется в каталог домашней папки Музыка.
Обязательные параметры none bind 0 0.
Таким образом вы можете прописать и другие каталоги по желанию.

Вот что получилось в моем случае:

В домашний каталог можно записать всего лишь 77 гигабайт, а в папку Видео можно записать почти 500 гигабайт информации.

Вот таким образом можно настроить свою систему.

Больше ничего делать не нужно с ssd. Не нужно настраивать commit, atime и прочую ересь, что несут в других блогах. Это все было актуально на старых моделях ssd, когда они только появились.

Вообще забудьте, что у вас SSD. Просто пользуйтесь им.

источник

Блог начинающего линуксоида.

советы, руководства, инструкции.

Страницы

понедельник, 10 июля 2017 г.

Ставим Debian 9 на SSD

Приобрёл недавно SSD накопитель Silicon Power Velox V55, на 60 Гб, дабы использовать его в качестве системного для Debian. Причина покупки очевидна — ускорение работы системы, увеличение скорости открытия программ и т.п. И хотя Debian у меня всегда летал как ракета на обычном HDD на 7200 оборотов и 64-х мегабайтным кэшем — можно сделать ещё круче. В интернете очень много статей по установки Линукса на SSD и сопутствующих оптимизациях, с целью увеличения качества работы накопителя и продления срока его службы. Вот только есть одна неочевидная проблема: многие эти статьи писались на основе того, какими были SSD в годы своего первого появления на массовом рынке. И для современных накопителей эта информация стала неактуальной, но пользователи продолжают верить что нужно делать именно так как написано в статье. Плюс ко всему часто не учитываются нюансы контроллеров в конкретных SSD — этот фактор тоже весьма важен, ведь контроллер — это сердце накопителя. И вот собрав кучу инфы, а также применив свои знания в этой области, установил на свою рабочую станцию новейший Debian 9. Делюсь своим опытом.

Файловая система.

Здесь я сделал выбор в пользу проверенной временем Ext4. Выбирал между тремя ФС — Ext4, Btrfs и F2FS. Btrfs, несмотря на долгие годы разработки, всё ещё может содержать ошибки, которые приводят к потере данных. Она несколько лучше подходит для SSD, нежели Ext4, но если вы давно читаете мои статьи, то знаете, что для меня надёжность на первом месте. К тому же мне просто не нужны две ключевые возможности этой ФС — снимки состояния системы и сжатие хранимых данных. Первое не нужно потому что я делаю бэкапы утилитой Clonezilla (старая привычка), а сжатие данных будет очень не оптимально работать с контроллером в моём SSD (SandForce). Что же касается F2FS — она специально создавалась для накопителей с NAND-памятью (SSD, флешки, SD-карты и подобное). Эта файловая система весьма молодая — Samsung её представила в 2012 году, спустя некоторое время её приняли в состав ядра Linux 3.8. О её надёжности судить не могу, но вот установка системы на неё весьма сложна. Во первых модуль этой файловой системы не загружается по умолчанию, и его нужно прописать в автозагрузку. Во-вторых — она недоступна из установщика большинства дистрибутивов. И система ставится на неё обычно переносом из существующего Ext4-раздела. Возможно заморочиться стоило, но я всё же выбрал Ext4. Однако на современных SSD-накопителях большой разницы между файловыми системами не будет, так как в самом накопителе находится контроллер FTL (File Transfer Layer), отвечающий за то, чтобы представить совсем непохожую на магнитные диски флеш-память как обычный диск, на который можно записать определенное количество блоков данных. Поэтому файловая система будет работать не напрямую с памятью накопителя, а через мини-прослойку, своего рода миниатюрную файловую систему в самом контроллере. Которая уже сама будет заниматься оптимальным размещением записываемых блоков данных.

Читайте также:  Установка вакуумного ко 505

Свободное место.

Для сохранения постоянной скорости записи SSD, его не рекомендуется заполнять больше чем на 75%. Плюс ко всему необходимо зарезервировать область, из которой контроллер будет брать блоки для замены повреждённых. Во всех современных SSD такая область уже зарезервирована, именно поэтому диск на 64 Гб продаётся как 60 Гб. 4 гигабайта ушло на эту резервную область. Что же касается заполнения диска — здесь я вообще не заморачивался, ибо вряд ли забью корень под завязку. Да и если забью — всё равно больше ничего туда не запишешь 🙂 А скорость чтения останется прежней. Тут гораздо важнее исправно работающий trim.

TRIM — команда интерфейса ATA, позволяющая операционной системе уведомить твердотельный накопитель о том, какие блоки данных уже не содержатся в файловой системе и могут быть использованы накопителем для физического удаления. Она крайне важна для нормальной работы и продления срока службы SSD, и выполнять её желательно раз в неделю. Здесь предлагается два способа — добавление опции discard в параметры монтирования диска (только для Ext4), или запуск команды fstrim, например настроив расписание по Cron. К слову в Fedora и Ubuntu по умолчанию для SSD применяется именно второй способ. А так как дискам на контроллере SandForce лучше не включать опцию discard, так как она будет замедлять работу накопителя во время выполнения TRIM — я выбрал второй способ. Только использовал для него я не Cron а systemd. Также стоит отметить, что при достаточном количестве свободного пространства (20 — 30%) можно вообще не включать опцию discard , даже на накопителях с контроллерами Marvell. Итак, что нужно сделать? В документации к util-linux есть готовые сервис-файл и таймер для запуска fstrim раз в неделю. Всё что нужно — скопировать их в /etc/systemd/system и активировать:

sudo cp /usr/share/doc/util-linux/examples/fstrim.service /etc/systemd/system
sudo cp /usr/share/doc/util-linux/examples/fstrim.timer /etc/systemd/system
sudo systemctl enable fstrim.timer

Опция noatime

Многие на просторах интернета советуют добавлять к параметрам монтирования SSD опцию noatime, которая отключает запись о последнем времени доступа при каждом чтении файла. Это может немного повысить производительность ввода-вывода, но некоторым программам (например почтовому клиенту Mutt) эта информация необходима, и noatime может нарушать работу подобных программ. Да и как показывают тесты — выигрыш небольшой. Поэтому я эту опцию не включал, и оставил включённый по умолчанию relatime.

Вопреки утверждениям из многих статей — раздел (или файл) подкачки МОЖНО и НУЖНО хранить на SSD. Если его оставить на HDD — будут серьёзные тормоза при обращении к нему. В случае же SSD он будет работать почти на скоростях оперативной памяти. Подкачка не увеличивает износ накопителя, и уж точно не сокращает срок его службы. Выбор тут такой — раздел или файл. Принципиальная разница в том, что файлов подкачки можно создать сколь угодно, и даже создавать их динамически, по мере необходимости, и потом удалять. Для этого есть замечательная утилита swapspace. Обращу внимание на несколько нюансов:

  • Для Btrfs сделать можно только раздел подкачки;
  • Если для Ext4 вы выбрали создание раздела подкачки — укажите в опциях его монтирования параметр discard, ибо подкачка не обрабатывается командой fstrim;
  • Не делайте раздел или файл больше 2-х гигабайт.

sudo apt install swapspace

Откроем конфиг демона и приведём его к такому виду:

sudo nano /etc/swapspace.conf

# security reasons this directory must be accessible to root and to root only.
swappath=»/var/lib/swapspace»

# Lower free-space threshold: if the percentage of free space drops below this
# number, additional swapspace is allocated
lower_freelimit=20

# Upper free-space threshold: if the percentage of free space exceeds this
# number, swapspace will attempt to free up swapspace
upper_freelimit=60

# Percentage of free space swapspace should aim for when adding swapspace. This
# should fall somewhere between lower_freelimit and upper_freelimit.
freetarget=30

# Smallest allowed size for individual swapfiles
min_swapsize=4m

# Greatest allowed size for individual swapfiles
max_swapsize=2g

# Duration (roughly in seconds) of the moratorium on swap allocation that is
# instated if disk space runs out, or the cooldown time after a new swapfile is
# successfully allocated before swapspace will consider deallocating swap space
# again. The default cooldown period is about 10 minutes.
cooldown=600

sudo systemctl restart swapspace

Раздел /home

Многие люди, покупая SSD таких малых объёмов, обычно используют их только для корневого раздела системы, а раздел с пользовательскими данными оставляют на обычном жёстком диске. Это в корне не правильно. В /home помимо ваших данных содержатся настройки программ, кэши и профили браузеров. И им тоже нужно очень быстро подгружаться, иначе какой толк в SSD? Я не стал рубить свой SSD на разделы как колбасу. Отдал его целиком под корень и /home, в качестве раздела для всякой помойки я подмонтировал раздел в 300 гигабайт с обычного жёсткого диска (монтировал в /media/DATA), на этом же разделе создал стандартные каталоги «Загрузки», «Видео», «Музыка» и так далее, а в домашнем каталоге создал на них символьные ссылки (ярлыки проще говоря):

Таким образом если, например, вы скачиваете что-то и оно сохраняется в папку «Загрузки» — браузер думает что сохраняет это в /home на вашем SSD, а на самом деле данные сохраняются на жёстком диске. Надеюсь понятно объяснил 🙂 Понятное дело что можно просто напрямую всё сохранять на раздел жёсткого диска, не создавая симлинки в /home, но лично мне так удобнее.

Читайте также:  Установка пластика на цоколь

Планировщик ввода-вывода.

Здесь мнения сильно разнятся. Кто-то использует CFQ и не видит смысла его менять, кто-то использует пока не попавший в основную ветку ядра Linux BFQ, кто-то Deadline и так далее. В чём разница?

CFQ — Completely Fair Queuing (полностью справедливая очередь) — стандартный планировщик ввода-вывода в Debian и многих других дистрибутивах. Разработан в 2003 году. Заключается его алгоритм в следующем. Каждому процессу назначается своя очередь запросов ввода/вывода. Каждой очереди затем присваивается квант времени. Планировщик же циклически обходит все процессы и обслуживает каждый из них, пока не закончится очередь либо не истечет заданный квант времени. Если очередь закончилась раньше, чем истек выделенный для нее квант времени, планировщик подождет (по умолчанию 10 мс) и, в случае напрасного ожидания, перейдет к следующей очереди. Данный планировщик отлично подходит для HDD, но не оптимален для SSD, так как время доступа к каждой ячейке на SDD одинаково.

NOOP — наиболее простой планировщик. Он банально помещает все запросы в очередь FIFO и исполняет их вне зависимости от того, пытаются ли приложения читать или писать. Планировщик этот, тем не менее, пытается объединять однотипные запросы для сокращения операций ввода/вывода. Этот планировщик гораздо лучше подойдёт для SSD, чем CFQ.

Deadline — стандартный планировщик в Ubuntu и многих других дистрибутивах. Разработан в 2002 году. В основе его работы, как это ясно из названия, лежит предельный срок выполнения — то есть планировщик пытается выполнить запрос в указанное время. В дополнение к обычной отсортированной очереди, которая появилась еще в Linus Elevator, в нем есть еще две очереди — на чтение и на запись. Чтение опять же более приоритетно, чем запись. Кроме того, запросы объединяются в пакеты. Пакетом называется последовательность запросов на чтение либо на запись, которая идет в сторону больших секторов («алгоритм лифта»). После его обработки планировщик смотрит, есть ли запросы на запись, которые не обслуживались длительное время, и в зависимости от этого решает, создавать ли пакет на чтение либо же на запись. Он также очень хорошо оптимизирован для SSD.

BFQ — относительно новый планировщик. Базируется на CFQ. Если не вдаваться в технические подробности, каждой очереди (которая, как и в CFQ, назначается попроцессно) выделяется свой «бюджет», и, если процесс интенсивно работает с диском, данный «бюджет» увеличивается. Штатно в ядре Linux появится скорее всего в выпуске 4.12, пока его можно задействовать патчингом ядра или применением ядер pf-kernel или zen-kernel. Также BFQ используется по умолчанию в Manjaro, ROSA и Calculate Linux. Хорошо подходит для SSD,

blk-mq — начиная с ядра 3.16, доступна поддержка блочного слоя blk-mq (multiqueue block layer), рассчитанного на организацию многопоточного доступа к данным на многоядерных системах и позволяющего эффективно использовать возможности современных SSD-накопителей. Архитектура нового блочного слоя основана на двухуровневой модели очередей: на первом уровне функционируют очереди для передачи запросов ввода/вывода, привязанные к каждому процессорному ядру. Из данных очередей запросы направляются в очереди второго уровня, которые координируют обращение к оборудованию. В зависимости от конфигурации системы, числа ядер и накопителей соотношение между очередями первого и второго уровня может составлять от 1 к 1 до N к M. Таким образом значительно повышается скорость чтения/записи, а также равномерно распределяется нагрузка. Для SSD это самый предпочтильный вариант, но. если у вас ещё будут HDD в системе, это плохо скажется на их производительности, так как поддержки планировщиков ввода-вывода в blk-mq пока нет. Точнее есть, но не в стоковом ядре Debian. Поэтому я отложил blk-mq до лучших времён, и задействовал планировщик Deadline для SSD, оставив CFQ для обычных жёстких дисков. В этом нам поможет udev — демон, отвечающий за монтирование дисковых накопителей. Создадим для него правило:

sudo nano /etc/udev/rules.d/60-schedulers.rules

# установка планировщика deadline для SSD
ACTION==»add|change», KERNEL==»sd[a-z]», ATTR==»0″, ATTR=»deadline»

TMPFS и Profile Sync Daemon

Про tmpfs я писал в отдельной заметке об оптимизации системы. Это RAM-диск — область в оперативной памяти, в которую происходит распаковка данных. В частности туда принято выносить каталог tmp, в котором содержатся временные файлы. Это серьёзно ускоряет работу, например, пакетного менеджера. Но я пошёл ещё дальше — перенёс в tmpfs профили и кэш браузеров. Сделать это крайне просто — всего навсего установить пакет profile-sync-daemon и указать в его конфиге нужные браузеры. Хотя и это можно не делать, тогда по умолчанию будут подхватываться все поддерживаемые браузеры. Суть работы этого псевдодемона в том, что он переносит в tmpfs профили и кеш браузеров, и периодически синхронизирует их с копиями на диске. По умолчанию синхронизация стоит на 1 час. Однако с такими браузерами как Chromium и Firefox есть небольшая загвоздка — их кеш хранится отдельно, и потому демон его не увидит. Внимание : profile-sync-daemon работает только с системным менеджером systemd. Если вы используете Sys V Init, Upstart или другие — то либо самостоятельно напишите init-скрипт, либо смените систему инициализации. По умолчанию в Debian 9 применяется systemd.

Сперва переместим /tmp в tmpfs:

tmpfs /tmp tmpfs defaults,size=2G,mode=1777 0 0

источник