Коротко и ясно о Linux и SSD
Недавно, хороший человек подарил мне SSD. Неделю он пролежал у меня на столе, т.к. времени перенастраивать систему под его использование не было. Когда же время появилось, прочитав вот этот пост habrahabr.ru/post/129551, и перелопатив немало форумов, узнал много нового.
Ниже предлагаю компиляцию всего усвоенного в одном тексте.
Итак, сперва теория:
1. ССД диск имеет ограниченное количество циклов перезаписи. Т.е. в один и тот же блок диска, в среднем, можно записать информацию 3000-5000 раз (на дорогие модели дисков можно и больше).
2. Что бы выравнивать износ диска, нужно как можно реже писать в одно и то же место, т.е. сперва использовать незанятые блоки диска, и только когда они кончатся, писать поверх.
3. В незанятый блок, ССД диск пишет намного быстрее чем в занятый.
4. Диск не «знает», о том, какие блоки заняты, т.к. эта информация сохраняется в файловой системе, и при удалении файла, фактически диску об этом не сообщается. Но когда файловая система решит повторно использовать блок, который уже когда то использовался, он может быть еще не очищен от информации которая там была, т.к. диск не знал, что его можно освобождать. И запись в такой блок займет много времени.
5. В отличие от HDD, в ячейку флеш-памяти NAND нельзя перезаписать новые данные поверх старых, не очистив ее перед этим. Ячейки памяти SSD сгруппированы в страницы (обычно по 4 Кбайт каждая), страницы сгруппированы в блоки (64-128 страниц). Данные можно вписать на чистую страницу, но стирать можно только блоки целиком. Запись на SSD-носитель выполняется очень быстро до тех пор, пока существуют чистые страницы, но значительно замедляется, если необходимо очищать предварительно записанные страницы. Чтобы вернуть в обращение ячейки блока, содержащего смесь актуальных данных и мусора (невалидных данных), контроллер копирует нужное (валидные данные) на пустую страницу нового блока, а затем стирает весь исходный блок. После этого ячейки блока будут готовы принять новые данные.
Так вот, что бы сообщать диску о освободившихся блоках, для равномерного использования диска, и для предварительной очистки блоков для последующей перезаписи, в интерфейсе ATA существует команда TRIM.
Что бы система начала использовать эту команду при удалении файлов:
1. диск должен поддерживать эту команду.
2. файловая система должна поддерживать эту команду.
3. функция TRIM в файловой системе должна быть включена.
А теперь все это на практике
Чтобы проверить поддерживает ли TRIM диск:
root@citadel:/home/serp# hdparm -I /dev/sdd|grep «TRIM supported»
* Data Set Management TRIM supported (limit 1 block)
Если получаем «Data Set Management TRIM supported (limit 1 block)», то поддерживается. Если слева от этой строки стоит звездочка, то функция активирована.
TRIM поддерживается в BTRFS, XFS, JFS и EXT4.
На данный момент, наиболее пригодна для использования EXT4.
Включить TRIM для файловой системы можно, если добавить discard в опции монтирования в /etc/fstab, или с помощью tune2fs -o discard /dev/sdaX (добавит discard в опции по умолчанию для данной ФС)
Проверить смонтирована ли ФС в данный момент с этой опцией можно посмотрев вывод mount:
/dev/sdd1 on / type ext4 (rw,discard,errors=remount-ro)
ВНИМАНИЕ. Нельзя отключать журналирование, т.к. функция TRIM без него работать не будет. Если верить вот этому источнику (https://wiki.archlinux.org/index.php/SSD#Partition_Alignment), то разница в количестве операций записи с журналом и без него не существенна, т.е. на время жизни диска особо влиять не будет (если только вы не используете его в режиме только для чтения, и хотите чтобы он жил вечно).
В интернетах часто советуют проверить включен ли TRIM таким способом:
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, перезагрузились, но трим не активировался — ищите ошибки в неверном отключении журналирования.
Так вот у меня не выдал нули. Но у меня из 60Гиг харда занято всего 20 (точнее занято всего 8, а 20 это размер раздела.) Я подозреваю, что диск не триммит данные пока не приспичит, или пока не появится много свободного времени.
Вот тут: sites.google.com/site/lightrush/random-1/checkiftrimonext4isenabledandworking по этому поводу написано, что если при таком тестировании, после шага 3, вы видите нули, значит TRIM однозначно работает. Если же вы нулей не увидели, то это еще не значит, что TRIM не работает. Возможно диск обнулит блок позже.
Для ускорения работы системы, за одно с перенастройкой под SSD я под шумок перенес /run и /tmp на tmpfs.
Скорость работы системы ЗНАЧИТЕЛЬНО ускорилась, точнее быстрее стали загружаться приложения, и быстрее загружается сама система.
Источник
Оптимизация 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 прослужит вам верой и правдой, и с каждым стартом будет радовать хорошей скоростью.
Источник
Ещё один блог сисадмина
воскресенье, 6 сентября 2020 г.
Оптимизация Linux при использовании SSD
Изменение планировщика ввода-вывода
По умолчанию Linux использует планировщик ввода-вывода cfq, который стремится упорядочить блоки данных так, чтобы уменьшить количество позиционирований головки с дорожки на дорожку диска. Для SSD это не имеет смысла, но приводит к задержке мелких операций ввода-вывода. Вместо планировщика cfq рекомендуется использовать планировщик deadline, который стремится сократить время ожидания выполнения каждой из операций ввода-вывода.
Изменить планировщик диска sda можно при помощи следующей команды:
Для того, чтобы выбранный планировщик диска применялся при загрузке системы, можно поставить пакет sysfsutils:
Оптимизация Linux при использовании SSD
И прописать планировщик в файл /etc/sysfs.conf:
Другой способ сделать изменения постоянными — создать файл /etc/udev/rules.d/60-ssd.rules со следующими правилами udev:
Это правило для всех не вращающихся дисков с именем sd* будет устанавливать планировщик deadline.
Размер страницы
Коэффициент усиления записи можно несколько уменьшить, если операционная система знает о размере страниц. В таком случае операционная система будет объединять изменения в смежных логических секторах, принадлежащих одной и той же странице, в одну операцию записи.
Например, по данным SMART размер логического сектора диска равен 512 байтам, а размер страницы равен 4096 байт:
Убедиться в том, что ядро операционной системы Linux знает о размере физического сектора, можно следующим образом:
Увеличение резерва страниц
Т.к. каждая страница SSD имеет ограниченный ресурс перезаписи, контроллер SSD в общем случае не записывает изменившиеся данные в ту же страницу, а использует другую. Чтобы с точки зрения операционной системы записанные данные оставались доступными по тому же адресу, контроллер использует специальный каталог соответствия страниц, который отображает линейное адресное пространство диска в реальные страницы. Чем больше неиспользуемых страниц имеется в распоряжении контроллера, тем больше у него возможностей выбирать наименее изношенные страницы для очередной операции записи, тем больше возможностей для уменьшения количества операций очистки блоков.
Часть общего объёма страниц диска закладывается в резерв. Напрмер, SSD объёмом 480 Гигабайт может иметь реальный объём 512 Гигабайт, а разница используется как раз для равномерного использования ресурса всех страниц.
Кроме того, в файловой системе может иметься свободное место, не занятое никакими данными. Это свободное место на SSD можно приобщить к резерву. Для этого операционная система может сообщать диску о неиспользуемых ею страницах при помощи ATA-команды TRIM. Для этого SSD должен поддерживать операцию TRIM, а файловая система должна поддерживать опцию монитрования discard.
Проверить наличие поддержки TRIM в SSD можно при помощи утилиты hdparm:
Вторая строчка означает, что секторы, над которыми произведена команда TRIM, при попытке чтения будут возвращать нули. Другим возможным режимом может быть «Deterministic read after TRIM», когда при чтении возвращаются не нули, а какая-то другая всегда одинаковая последовательность данных.
Если на странице руководства man mount среди опций интересующей файловой системы имеется опция discard, то файловую систему можно перемонтировать с поддержкой этой опции.
Сначала посмотрим, с какими опциями смонтирована файловая система:
Перемонтируем файловую систему, добавив к списку опций remount и discard:
Убеждаемся, что новая опция добавилась к текущему списку:
Чтобы отключить опцию discard, можно повторить процедуру перемонтирования, указав вместо опции discard опцию nodiscard.
Чтобы при перезагрузке операционная система монтировала файловую систему с опцией discard, нужно добавить её к списку опций монитрования в файле /etc/fstab. Например, строчка монтирования может выглядеть следующим образом:
Чтобы сообщить диску о неиспользуемых секторах, которые были освобождены до включения опции discard, или при отключенной опции discard, можно воспользоваться командой fstrim:
Кроме увеличения ресурса диска, использование TRIM и discard может приводить к увеличению скорости операций записи и чтения. Т.к. у контроллера есть в распоряжении много очищенных блоков, ему не придётся тратить время на их очистку для записи новых данных. При этом операция очистки блока может выполняться в фоновом режиме, когда SSD не занят выполнением операций чтения или записи.
Источник
