Ставим 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), отвечающий за то, чтобы представить совсем непохожую на магнитные диски флеш-память как обычный диск, на который можно записать определенное количество блоков данных. Поэтому файловая система будет работать не напрямую с памятью накопителя, а через мини-прослойку, своего рода миниатюрную файловую систему в самом контроллере. Которая уже сама будет заниматься оптимальным размещением записываемых блоков данных.

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

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

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.

SWAP

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

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

Я выбрал swapspace:

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), на этом же разделе создал стандартные каталоги "Загрузки", "Видео", "Музыка" и так далее, а в домашнем каталоге создал на них символьные ссылки (ярлыки проще говоря):

ln -ls ~/Загрузки /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{queue/rotational}=="0", ATTR{queue/scheduler}="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:

sudo nano /etc/fstab

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

Я выделил 2 гигабайта под него (памяти у меня 8 гигов).

Ставим profile-sync-daemon:

sudo apt install profile-sync-daemon
psd

Для Chromium, Firefox, Midori и Rekonq необходимо перенести каталог с кэшем в каталог с профилем браузера, и создать символьную ссылку вместо него на путь к каталогу с кешем. Для Firefox:

mkdir /home/$USER/.mozilla/firefox/cache

cp -r /home/$USER/.cache/mozilla/ /home/$USER/.mozilla/firefox/cache

rm -rf /home/$USER/.cache/mozilla/

ln -s /home/$USER/.cache/mozilla /home/$USER/.mozilla/firefox/cache

Таким образом при перемещении профиля браузера в tmpfs, profile-sync-daemon захватит с собой ещё и кэш. Время синхронизации с дисковой копией можно указать в конфигурационном файле. Я укажу 10 минут:

sudo nano /usr/lib/systemd/user/psd-resync.timer

[Unit]
Description=Timer for Profile-sync-daemon - 10min

[Timer]
OnUnitActiveSec=10min

Отлично. Но можно сделать ещё лучше. Например уменьшить размер занимаемых данных profile-sync-daemon в tmpfs и увеличить скорость синхронизации. В этом нам поможет слоёная файловая система Overlayfs. Особенность метода в том, что overlayfs записывает только измененные данные, а не весь профиль. Для этого необходимо предоставить этой ФС права root, а также включить её в конфиге profile-sync-daemon:

sudo nano /etc/sudoers

Ищем строку:

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

и дописываем под ней

sunderland93 ALL=(ALL) NOPASSWD: /usr/bin/psd-overlay-helper

Замените sunderland93 на имя вашего пользователя. Теперь включим Overlayfs. Для этого раскомментируйте (уберите # в начале строки) строку USE_OVERLAYFS="no" в /home/$USER/.config/psd/psd.conf и измените её значение на Yes . Если в профилях браузера хранится много данных, или самих профилей много - нужно выделить побольше места под эти данные в tmpfs. По умолчанию установлен лимит в 10% от количества оперативной памяти. Я не жмот, и выделил 20%. Открываем файл:

sudo nano /etc/systemd/logind.conf

Раскомментируем строку RuntimeDirectorySize=10% и меняем на 20%. Сохраняем всё и активируем демона:

systemctl --user enable psd
systemctl --user start psd 

Проверить его состояние можно командой psd p :

 Systemd service is currently active.
 Systemd resync-timer is currently active.
 Overlayfs v23 is currently active.

Psd will manage the following per /home/sunderland93/.config/psd/.psd.conf:

 browser/psname:  google-chrome/chrome
 owner/group id:  sunderland93/1000
 sync target:     /home/sunderland93/.config/google-chrome
 tmpfs dir:       /run/user/1000/sunderland93-google-chrome
 profile size:    348M
 overlayfs size:  95M
 recovery dirs:   none


На этом всё. Удачных оптимизаций!