- Активация discard (TRIM) на Linux для SSD
- discard в суперблоке EXT4
- discard в fstab
- discard на LVM
- discard для зашифрованного root-раздела
- discard для других зашифрованных разделов устройства
- Проверка TRIM
- Оптимизация Ubuntu (и прочих Linux-ов) под SSD
- Самый актуальный гайд по установке Linux на SSD-накопители в 2021 году
- Насколько готовы современные дистрибутивы Linux к установке на SSD?
- Как подготовить SSD-накопитель к установке Linux-системы?
- О журналировании и бэкапе при выборе файловой системы
- Как настроить разделы и сколько оставить неразмеченной?
- Как следует настраивать актуальные сборки на базе Linux под SSD?
- Как измерить скорость работы SSD в Linux?
- Вердикт: смело монтируйте Linux на SSD без заморочек
Активация discard (TRIM) на Linux для SSD
Современные накопители данных такие как SSD нуждаются в команде TRIM интерфейса ATA и для этого в ОС построенных на базе ядра Linux предусмотрено два метода управления на уровне файловых систем:
- discard — устанавливается как опция монтировании файловой системы. Позволяет ядру Linux сразу отправлять команду TRIM на устройство, как только об этом сообщит файловая система.
- fstrim — утилита которая запускается вручную или по расписанию как сервис ОС, отправляет список удаленных блоков с ФС для зачистки их на устройстве.
Для включения fstrim достаточно активировать сервис fstrim.service в systemd, но лучше вместо сервиса, который будет висеть в памяти, использовать таймер fstrim.timer который будет запускать еженедельный TRIM.
Пример включения сервиса:
Но этих мер недостаточно, если у вас файловые системы располагаются на томах LVM, а LVM в LUKS игла в яйце, яйцо в утке, утка в зайце :
Первое что нужно сделать, это проверить, что контроллер SATA работает в режиме AHCI, а не IDE, иначе TRIM работать не будет:
Ключевое слово здесь это TRIM supported , значит контроллер SATA работает в режиме AHCI и вам не нужно ничего менять в BIOS или UEFI.
Итак, опция discard может устанавливаться:
- в суперблоке ФС (как опция монтирования по умолчанию)
- в конфигурации монтирования ФС — /etc/fstab
- в конфигурации cryptsetup — /etc/crypttab
- в конфигурации LVM — /etc/lvm/lvm.conf
- в конфигурации загрузчика — /boot/grub/grub.cfg
Мы рассмотрим все эти варианты. Примеры будут даны для дистрибутива Arch Linux и его производных, но я думаю вас не затруднит адаптировать тему к любому другому дистрибутиву Linux.
discard в суперблоке EXT4
Если в /etc/fstab для файловой системы опция discard не указана или в опциях монтирования указана опция defaults , то система будет использовать опции монтирования прописанные в суперблоке файловой системы. Это актуально для файловой системы EXT4. Запись опций монтирования в суперблоке ФС может быть выгодна тем, что если у вас съёмное устройство которое подключается по SATA к разным машинам в которых вы не можете по каким-то причинам вносить изменения в /etc/fstab .
Добавляем опцию монтирования discard по умолчанию в суперблок файловой системы EXT4. У меня это три раздела:
Убедиться в установленной опции можно через tune2fs . Здесь /dev/mapper/vg1-lvroot это устройство, раздел с файловой системой EXT4 в томе LVM:
discard в fstab
Если это единственная система куда разделы SSD будут монтироваться, то мы можем прописать опцию discard явно в /etc/fstab для автомонтирования разделов, но устанавливать опцию необязательно для EXT4, если она уже была ранее задана в суперблоке.
Также, опцию discard следует добавить для swap раздела:
discard на LVM
В конфигурационном файле /etc/lvm/lvm.conf устанавливаем значение опции issue_discards в значение равное 1 :
Важно отметить, что включение этой опции не пересылает команду TRIM с файловых систем когда на них производятся команды удаления файлов, эта опция посылает команду TRIM только когда производятся манипуляции изменения логического тома, например, через такие команды как lvremove, lvreduce и т.д.
discard для зашифрованного root-раздела
Прежде, чем вы решите включить discard на зашифрованных томах, необходимо оценить риск безопасности утечки метаданных (тип файловой системы, используемое пространство и т. д.) которые могут быть извлечены из физического устройства при его завладении нежелательными лицами, об этом говорит предупреждение в мануале crypttab :
WARNING: This command can have a negative security impact because it can make filesystem-level operations visible on the physical device. For example, information leaking filesystem type, used space, etc. may be extractable from the physical device if the discarded blocks can be located later. If in doubt, do not use it.
Если вы Джеймс Бонд или секретный агент который занимается незаконными делами или работаете с гостайной и рискуете потерять жизнь, то эту опцию нежелательно использовать. В иных случаях, для простого пользователя, который шифрует разделы на устройстве с целью защиты информации от посторонних глаз, защиты себя и своих близких от шантажа неким домашним хакером в случае кражи ноута или устройства, то возможно ли расшифровать данные, если злой хакер получит метаданные файловой системы? Каким уровнем знаний должен обладать этот хакер, чтобы справится с расшифровкой данных? Какова цена? Предлагаю обсудить это в комментариях 🙂
В приведенной выше схеме разметки таблицы разделов на накопителе, некоторые разделы являются зашифрованными и «заперты» в криптоконтейнере LUKS. Чтобы TRIM был разрешен для этих разделов, корневой раздел должен быть открыт cryptsetup ‘ом с аргументом —allow-discards или опция должна быть прописана в /etc/crypttab для нужного раздела, но проблема заключается в том, что мы не можем прописать опцию в /etc/crypttab , так как root-раздел в нашей схеме изначально зашифрован и система не может прочитать его до того как откроет криптоконтейнер.
Решением этой проблемы является указать опцию при открытии криптоконтейнера на раннем этапе загрузки в initramfs, а передать эту опцию в initramfs поможет опция в конфигурации загрузчика grub для ядра Linux.
Добавляем значение allow-discards в конфигурационный файл /etc/default/grub для параметра cryptdevice в параметре для ядра GRUB_CMDLINE_LINUX .
Меняем эту строчку:
Затем необходимо сгенерировать «правильный» конфиг grub’а:
Также проверьте, что у вас образ initramfs скомпилирован с хуком encrypt который позволяет открывать криптоконтейнеры с помощью cryptsetup и он расположен до хука lvm2 :
После внесения изменений в grub систему следует перезагрузить для применения изменений.
discard для других зашифрованных разделов устройства
В приведенной выше схеме разметки, раздел /home не является корневым и находится в контейнере LUKS. В этом случае, следует прописать опцию монтирования discard в конфигурационном файле /etc/crypttab который зачитывается системой до зачитывания и выполнения /etc/fstab .
Формат записи опции в конфигурационном файле вы найдете в мануале: man crypttab
Проверка TRIM
Выполните следующую команду:
Если вы видите нулевые значения в колонках DISC-GRAN (discard granularity) и DISC-MAX (discard max bytes), значит TRIM не работает.
Проверить еще можно командой ручного вызова TRIM:
Если вы видите положительный результат, значит TRIM работает. При полной поддержке TRIM значения должны быть на всех разделах:
Здесь DISC-GRAN равен 512B потому что размер сектора на моём SSD равен 512 bytes. Операционная система посылает команду TRIM контроллеру накопителя с указанием номеров секторов, которые могут быть очищены. Размер вашего сектора можно узнать из следующих команд:
UPDATE 14.04.2020 14:20: Добавил предупреждение использования опции на зашифрованных томах. Спасибо AAngstrom который отметил в комментариях это упущение.
UPDATE 23.04.2020 22:00: Подправил текст, убрал слово «диск» из текста, так как оно не соответствует описываемому в статье устройству. Спасибо vitaliy2
Источник
Оптимизация Ubuntu (и прочих Linux-ов) под SSD
Доброго времени суток всем читающим. В данной мини-статье мне хотелось бы собрать и рассмотреть основные моменты оптимизации работы (и, конечно, продления жизненного цикла ) твердотельных накопителей. Практически всю информацию можно легко найти в сети, но тут я попытаюсь упомянуть пару подводных камней.
Первое, с чего стоит начать — это выбор файловой системы. Если система на десктопе — то особо вопросов не возникает — брать журналируемую ext4 — у которой масса преимуществ перед остальными ФС. Да, будет больше циклов записи на носитель, но будет гарантия того, что в случае сбоя питания вы не потеряете данные. На ноутбуках, нетбуках — имеются батареи, и вероятность отключения из-за потери питания — практически нулевая (но, конечно, всякое бывает), в связи с чем журналирование, обычно рекомендуют отключать. Если это очень хочется сделать, то после установки системы грузимся с liveCD, и пишем в терминале
tune2fs -O ^has_journal /dev/sda1
e2fsck -f /dev/sda1
Другие способы не рекомендуются — потеряете поддержку TRIM. Также не стоит отключать журнал, добавляя параметр «writeback» в конфигурацию fstab — система не запустится из-за ошибки монтирования (если до этого был включен трим).
Следующее, что нужно учесть — файл подкачки. Под моим никсом (сейчас — убунту 11.04) обычно пишется код, смотрятся фильмы в HD и активно серфится интернет. За это время файл подкачки не понадобился ни разу, максимальное потребление ОЗУ было 1Гб, из 2х доступных в нетбуке.
Если Ваш сценарий использования системы подобен моему, или у Вас не десктоп — файл подкачки не нужен. Иначе стоит его перенести на HDD. Если журналирование еще можно оставить, ввиду его относительной безобидности, то своп-раздел — однозначно зло, сжирающее как ограниченные циклы перезаписи, так и недешевые гигабайты, количеством которых современные SSD пока не могут похвастаться.
Ну вот, система поставлена — можно заниматься оптимизацией! Самый первый шаг — включение TRIM — главная технология, которая должна продлить жизнь и распределить нагрузку SSD.
Делается очень просто — открываем fstab (например так)
gksudo gedit /etc/fstab
ищем строчки
«UUID=[NUMS-AND-LETTERS] / ext4 errors=remount-ro 0 1»
и заменяем на
«UUID=[NUMS-AND-LETTERS] / ext4 disсard,errors=remount-ro 0 1»
Обычно по умолчанию трим отключен, но выкладываю способ проверить — заходим под рут и выполняем команды
1. dd if=/dev/urandom of=tempfile count=10 bs=512k oflag=direct //запись 5Мб рандомных данных
2. hdparm —fibmap tempfile //Ищем любой стартовый LBA адрес у файла
3. hdparm —read-sector [ADDRESS] /dev/sdX //Читаем данные со стартового LBA адреса файла, замените [ADDRESS] на свой Starting LBA address из вывода предыдущей команды
4. rm tempfile //Теперь удалим временный файл и синхронизируем ФС:
5. sync
Повторяем пункт 3 — и смотрим на вывод консоли. Если выведутся нули — то трим работает. Если вы исправили fstab, перезагрузились, но трим не активировался — ищите ошибки в неверном отключении журналирования.
Далее стоит вспомнить о том, что наш никс очень любит вести разнообразные логи. И либо перенести их на HDD, либо держать в ОЗУ до перезагрузки системы. Я считаю, что если у Вас дома не сервер — то оптимален второй вариант, и реализуется он добавлением в fstab следующих строчек
tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/tmp tmpfs defaults 0 0
tmpfs /var/lock tmpfs defaults 0 0
tmpfs /var/spool/postfix tmpfs defaults 0 0
По умолчанию, после каждого открытия файла — система оставляет отметку времени последнего открытия — лишние операции записи. Отучить просто — добавить в fstab перед параметрами
disсard,errors=remount-ro 0
еще парочку опций —
relatime,nodiratime Первая разрешает записывать только время изменения (порой необходимо для стабильной работы некоторых программ), вторая — отменяет запись времени доступа к директориям. В принципе, вместо relatime можно поставить и noatime, который вообще ничего не будет обновлять.
После этого стоит настроить отложенную запись — ядро будет копить данные, ожидающие записи на диск, и записывать их либо при острой необходимости, либо по истечении таймаута. Я ставлю таймаут на 60 секунд, кто-то — на 150.
Для этого открываем /etc/sysctl.conf и добавляем параметры
vm.laptop_mode = 5 // Включение режима
vm.dirty_writeback_centisecs = 6000 время в сСк. Т.е. 100ед = 1секунда
И, напоследок, отключаем I/O планировщик, который был когда-то нужен для лучшего позиционирования головок HDD. Для этого заходит в конфиг граба /etc/default/grub
и в строчку
GRUB_CMDLINE_LINUX_DEFAULT=«quiet splash» вставляем параметр elevator=noop
По пути можно убрать ненужный и малоинформатиынй сплэш-скрин, сократив время старта системы еще на секунду, просто убрав quiet splash.
Вот, в общем основные моменты. Дальше стоит проявить фантазию — например, перенести куда-нибудь, или вовсе отключить кеш браузеров и тд. В награду за проделанные манипуляции Ваш SSD прослужит вам верой и правдой, и с каждым стартом будет радовать хорошей скоростью.
Источник
Самый актуальный гайд по установке Linux на SSD-накопители в 2021 году
Привет, Хабр! Долгие годы по сети гуляют байки о тайных умениях спецподготовки твердотельных накопителей к установке Linux-дистрибутивов. Пользователей-новичков это отпугивает — перейти на OpenSource типа Ubuntu. А давно не следящих за новинками железа — оттягивает прокачать скорость работы. В этом посте мы отбросим все мифы и неактуальные советы, прочно засевшие в топе поисковых запросов. А заодно подскажем ряд простых и эффективных советов по установке Linux на SSD-накопители. Поехали!
Недавно мы уже рассказывали о типичных ошибках использования твердотельных накопителей любителями лайфхаков и прочих улучшений. Тема ошибок при эксплуатации SSD вызвала неподдельный интерес в комментариях, где была затронута популярная байка о тонкостях и секретах настройки Linux при установке на SSD-накопители. Та самая, что активно обсуждалась в холиварах на форумах и породила множество подробных гайдов на просторах Хабра. Если вдруг кто не в курсе, можете загуглить “установку Linux на SSD”.
С большой долей вероятности, поисковая выдача отправит вас прямиком во времена доллара по 30 рублей и новейших процессоров Intel Core под Socket H2. Эх, ностальгия!
Тогда вопросы надежности и долговечности первых твердотельных дисков всерьез волновали сторонников Linux-систем. Особенно тех, кто не обращал внимание на журналирование файловых систем поколения Ext3. К примеру, важная для NAND-памяти процедура TRIM выполнялась по умолчанию лишь раз в неделю, нанося серьезный урон ячейкам в масштабах нескольких лет эксплуатации. Но главное, на что мы рекомендуем сейчас обращать внимание при чтении подобных гайдов и секретов: дата публикации. Ладно когда гайду 5-6 лет, но у большинства и вовсе скоро юбилей.
Насколько готовы современные дистрибутивы Linux к установке на SSD?
Не пытайтесь изобрести колесо. Современные дистрибутивы Linux хорошо оптимизированы под установку на твердотельные накопители и автоматически выставляют оптимальные параметры журналирования и ежедневного обновления TRIM, а также деликатно относятся к записи кэша на диск. Начиная с Ubuntu версии 14.04 твердотельные диски корректно определялись еще на этапе установки, оставляя пользователю лишь иллюзию выбора неправильной файловой системы вместо рекомендуемой Ext4. Все остальное вторично, а 99% проверяющих через консоль активность TRIM на SATA-дисках, неизменно обнаруживали корректные значения вместо нулей.
Повторимся — наш совет простой: прежде чем тратить время на чтение гайдов и лайфхаков по установке Linux-систем на SSD-диск, взгляните на дату публикации. На одном из Ubuntu-сообществ от некогда грандиозного Wiki-склада полезных команд остался лишь пяток абзацев, типа проверки активности утилиты TRIM. Все современные версии той же Ubuntu динамически отслеживают параметры работы дисковой подсистемы и по умолчанию стараются минимизировать число паразитных операций с кэшем вне оперативной памяти.
Как подготовить SSD-накопитель к установке Linux-системы?
На сегодняшний день можно смело урезать советы по подготовке твердотельного диска для Linux до советов по выбору подходящего носителя по типу и емкости. Вместо поиска альтернатив файловой системе Ext4 (стандарт де-факто) лучше потратить время на изучение отличий между NAND-чипами с QLC, TLC и другими видами компоновки ячеек. Подробнее о выборе накопителей по признаку QLC и их теоретических недостатках мы подробно рассказывали в этом посте. Если вкратце, SSD-накопители с QLC-ячейками дешевле, а TLC применяются во флагманских решениях, обеспечивая лучшую наработку на отказ и более высокую скорость передачи данных. Продукция Kingston построена на базе передовых 3D TLC и 3D NAND ячеек памяти, лишенных недостатков 4-битных QLC.
Но раскрыть потенциал памяти на ячейках 3D TLC и 3D NAND можно лишь с применением SSD-накопителей формата M.2, подключаемых напрямую к шине PCI-E x4. В линейке накопителей Kingston вы можете выбрать наиболее производительные M.2-накопители линейки KC2500 с предельной скоростью чтения/записи 3500/2500 МБ/с уже для моделей c емкостью от 500 ГБ. Ячейки выполнены по 96-слойной технологии 3D TLC, а производительность контроллера Silicon Motion 2262EN давно стала неким стандартом.
В сегменте M.2-накопителей с ячейками 3D NAND одним из самых популярных решений Kingston являются SSD из линейки A2000. Модели на 500 и 1000 ГБ демонстрируют скорость чтения/записи на отметке 2200/2000 МБ в секунду, а младшая — 2000/1100 МБ/с.
Если же планируете подключать диск по SATA, гнаться за скоростями выше 560 МБайт/с не имеет смысла — упретесь в лимит по шине. Выгоду следует искать в емкости доступного пространства. В линейках Kingston A400 и KC600 доступны твердотельные SATA-диски вместимостью до 2 ТБ. Отличия бюджетной линейки A400 от старшей кроется в использовании ячеек памяти TLC вместо 3D TLC, что напрямую влияет на цену и показатель наработки по числу записываемых байтов информации.
Рекомендовать младшие SATA-диски под систему можно с рядом оговорок, но под отдельные разделы системы и данные эти решения могут оказаться не сильно дороже компактного жесткого диска, превосходя по скорости даже RAID-массивы из винчестеров бытового сегмента.
Ориентироваться на разницу значений по наработке до отказа у твердотельных SATA-накопителей не столь важно. Как минимум, важнее заложить в бюджет обновления дискового массива качественное питание компьютера, начиная с блока питания и заканчивая сетевым фильтром и бесперебойником. Твердотельные накопители в целом довольно слаботочные решения по сравнению с жесткими дисками, и некачественное питание может свести к нулю всю выгоду от показателя в 1 миллион часов по MTBF.
О журналировании и бэкапе при выборе файловой системы
Возвращаемся к проблеме вреда от чрезмерной заботы по сохранности SSD-накопителей. Бывает, что пользователи отказываются от журналирования вовсе, или вставляют HDD-костыли для снижения паразитных операций перезаписи ячеек. Вообще, применение жестких дисков в паре с твердотельным накопителем можно советовать лишь для хранения крупных мультимедийных файлов (типа кино и музыки), ведь перенос системного кэша и логов на жесткий диск моментально сведет к нулю всю прибавку скорости SSD.
Другое дело — бэкап и все резервные копии. В отличие от сомнительной пользы RAID-массивов из твердотельных накопителей вне промышленных систем хранения данных, резервное копирование информации и образов системы напрямую влияет на сохранность ваших данных. Подстраховка жестким дискам в подобных случаях уместна, но только в случаях, когда IOPS не превышает ваш лимит по стоимости.
С резервным копированием в бытовых условиях лучшим выходом может оказаться сетевое хранилище, чье влияние на производительность операционной системы на твердотельном диске будет сведено к минимуму. С кэшем и минимизацией числа мелких обращений к ячейкам памяти, три четверти которых не превышают по размеру саму ячейку в 4 Кб, лучше всего бороться достаточным запасом свободной оперативной памяти. Современные дистрибутивы Ubuntu по умолчанию хорошо отлажены для использования оперативки под кэш, сводя выгрузку в виртуальную память до нескольких обращений за день.
Как настроить разделы и сколько оставить неразмеченной?
В вопросах эффективности разделения SSD-накопителей на массив логических разделов мы не рекомендуем пытаться искать связи с продлением срока службы носителя. Заложив изначально 25-30% хранилища свободными от данных, вы внесете максимальный вклад в срок безотказной и верной службы диска, а потому вольны свободно размечать до 4-х разделов в рамках Ext4. Другой вопрос, что современные высокоскоростные носители данных можно подключить как USB-C флешку и перекинуть туда некоторые разделы системы.
Создавать несколько логических разделов имеет смысл лишь для разнесения каталогов системы с различным характером применения. Например, системные и бинарные каталоги имеет смысл разделить от логов, как и резервные базы. А вот потребности /run лучше покрыть запасом по доступной оперативной памяти. Это наилучшим образом скажется на снижении IOPS на диск в течении длительного периода эксплуатации.
Как следует настраивать актуальные сборки на базе Linux под SSD?
На протяжении последних трех лет ответ на данный вопрос звучит до неприличия просто: отдавайте предпочтение настройкам по умолчанию. Постарайтесь отказаться от ручной корректировки параметров с помощью устаревших гайдов, а некорректное выполнение некоторых из них может привести к потере данных. Напомним, что операция удаления на SSD-накопителях гораздо честней жестких дисков и сложней по восстановлению. К тому же современные емкости в сотни недорогих гигабайт и типичная наработка на отказ в 50-70 ТБ потребует десятки лет работы Linux в домашних условиях.
Даже широко обсуждаемое включение ежедневного запуска TRIM уже несколько лет как потеряло свою актуальность. Данная процедура автоматически запускается всеми современными Linux-дистрибутивами. В этом абзаце речь идет о большей части советов, где упоминается Fstab, пользовательские наработки по которому давно стали базовой частью системы.
Выходит, что никаких отличий по настройке, при установке Linux системы на SSD и жесткий диск, нет вовсе. Можете смело доверить заботу о твердотельном накопителе системе, позаботившись запасом доступной оперативной памяти под нагрузкой. 32 ГБ гарантированно покроют этот вопрос у 99% пользователей, а проверить текущие значения потребления можно простой командой free.
Как измерить скорость работы SSD в Linux?
Если десять лет назад еще можно было встретить упоминания Phoronix test suite, на сегодняшний день стандартом бенчмарков в бытовых, рабочих и серверных машинах является утилита Fio. В умелых руках с ее помощью можно оперативно измерить окупаемость масштабирования СХД по стоимости IOPS, но в бытовых целях вас наверняка интересуют те же значения, что выдает на Windows утилита CrystalDiskMark, не так ли?
Ее аналог доступен на просторах Github под именем KDiskMark. У программы есть графический интерфейс, сводящий проверку скорости накопителей и любых дисков до пары кликов мышкой. За оболочкой скрывается вышеупомянутая Fio, итоговые значения которой наиболее точны в сравнении измерений диска на других ОС.
Вердикт: смело монтируйте Linux на SSD без заморочек
Более подробный анализ значений работы SSD-дисков требует более обстоятельного подхода и широко освещен Хабровчанами. Базовую информацию, разметку и проверку дисковых разделов можно выполнить с помощью утилиты Disks, предустановленной в Ubuntu и многих других Linux-дистрибутивах. А 99% всех рекомендаций и твиков давно утратили свою актуальность. Сегодня вы можете наслаждаться быстрой работой Linux-систем на твердотельных накопителях Kingston без дополнительных танцев с бубнами, просто выбрав установку по умолчанию.
Для получения дополнительной информации о продуктах Kingston Technology обращайтесь на официальный сайт компании.
Источник