Объем ssd для linux

Ещё один блог сисадмина

воскресенье, 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 не занят выполнением операций чтения или записи.

Источник

Установка Ubuntu Linux на SSD.

Многие слышали, что на рынке появились твердотельные жёсткие диски без движущихся частей, SSD диски. Они пока относительно дорогие и объем не велик, но операционная система на них просто летает, а тяжёлые приложения стартуют в разы быстрее, чем с обычных HDD. Чем достигается такое волшебство?

У SSD нет головок, которые необходимо позиционировать над затребованными данными и поэтому скорость чтения случайных секторов происходит намного быстрее. А как показывает практика, именно работа с мелкими файлами, расположенных в разных местах диска — это обычный портрет работы операционной системы.

Лучшее решение на сегодняшний день — это покупка SSD для операционной системы и хранение личных и медиа файлов на обычных HDD.
Вот и я решился купить себе SSD диск для Ubuntu. Много прочёл про этот новый вид дисков — твердотельные накопители. Хотел модель Intel X25-V, но денег как всегда мало, пришлось приобрести модель OCZ «Onyx» OCZSSD2-1ONX32G с контроллером Indilinx Amigos, про который много отрицательного не пишут.

Ниже описаны этапы, которые помогут правильно подготовить SSD для работы с Ubuntu Linux. Если вы проигнорируете этапы, то получите работающую систему, но не оптимальную, с меньшей скоростью чтения-записи и, возможно, подвергните свой SSD диск опасности раннего выхода из строя.

Прочтите все о вашем SSD на официальном сайте

Не пренебрегайте данным советом, например я вычитал на официальном сайте моего OCZ «Onyx» OCZSSD2-1ONX32G, что обновлять прошивку нужно, установив в BIOS, режим IDE для SATA дисков, а не родной AHCI режим. Мало ли чего важного вы вычитаете?

Обновите прошивку

Внутри жёстких дисков, SSD не исключение, есть микроконтроллер, который управляется микропрограммой. Её можно обновлять и это называется «прошивкой» (firmware). Прочтите что и как рекомендует производитель вашего SSD диска для обновления прошивки. Обычно обновление прошивки устраняет ошибки и добавляет новые функции. Очень важно чтобы SSD диск поддерживал TRIM и, если для этого нужно обновить прошивку, обновляйте!

Узнать текущую версию прошивки можно командой sudo hdparm -i /dev/ваш_диск | grep -i Fw

Выравнивание разделов на SSD

Суть проблемы в том, что если начало разделов в секторах не кратно размеру кластера файловой системы, то резко падает производительность при чтении/записи с диска, а в случае с SSD диском ещё и увеличивается износ диска. То есть когда разделы не выравнены, то кластер файловой системы занимает несколько секторов и тем самым увеличивается количество операций чтения/записи. Подробнее об этой проблеме выравнивания разделов лучше прочесть в Интернете. Главное запомнить простое правило: создаёте раздел — его стартовый сектор должен делиться на 8 без остатка.

Устр-во Загр Начало Конец Блоки Id Система
/dev/sdh1 2048 514047 256000 83 Linux
/dev/sdh2 514048 55810047 27648000 83 Linux

Начальные сектора 2048 и 514048 кратны 8! Я использовал fdisk и в нём создал разделы /boot, / и swap. Из статьи на Хабре выяснил, что работа со swap в современных операционных системах идёт примерно

40:1 чтение:запись. Поэтому размещение swap на SSD это отличная идея. Чуть позже мы заставим Ubuntu Linux меньше использовать swap, а больше быструю ОЗУ.

Некоторое место на вашем SSD зарезервировано и недоступно вам, это место будет использовано для замены износившихся во время записи-перезаписи ячеек. Во время разметки диска, я оставил не размеченой область

3,5 Гб, чтобы контроллеру диска было чем заменять, в далёком будущем, вышедшие из строя ячейки. Вам так же рекомендую не жадничать и при разметке оставить чуток не размеченной области.

Установка на SSD Ubuntu

Во время установки я указал, что первый раздел на SSD это /boot и файловая система ext3. Просто я решил помочь grub’у и не огребать не нужных проблем. В /boot хранятся ядра системы и размера 250 мб должно хватить на много установленных параллельно ядер.

Второй раздел на SSD стал корнем / в BTRFS. У этой продвинутой файловой системы, есть замечательный параметр -o ssd. Указав его, мы сообщаем, что жёсткий диск вида SSD и улучшаем работу с ним. Указать параметр можно позже, отредактировав /etc/fstab

# мой корень
UUID=6f1fedb8-2dc7-4d19-a1f4-2eac082f879e / btrfs defaults,noatime,barrier=0,nodatacow,discard,commit=600,ssd 0 0

Раздел /home был и его не форматируя через установщик, я задействовал как и раньше. Все файловые системы, кроме /boot, указаны в BTRFS.

Оптимизация Ubuntu для SSD

Если у вас есть UPS, он же ИБП, то можно применить советы из Ускорение Ubuntu.

Параметр discard.
Включает полезную команду TRIM и настоятельно рекомендуется к применению к различным файловым системам. discard нужно указать в /etc/fstab. Разработчики многих дистрибутивов linux обсуждали иногда возникающую проблему с discard, которая приводит к падению производительности. Альтернативным путём является вызов fstrim из cron. Пробуйте и выбирайте своё!

Параметр ssd для btrfs.
Указывайте для файловых систем btrfs в /etc/fstab.

Параметр commit=600.
Замечательный параметр commit равный 600 можно применять ко многим файловым системам и commit указывает на сброс грязных файловых буферов каждые 10 минут (600). Настоятельно рекомендуется иметь ИБП. commit=600 нужно указать в /etc/fstab.

barrier=0
Код файловой системы обязан перед созданием записи фиксации [журнала] быть абсолютно уверенным, что вся информация о транзакции помещена в журнал. Просто делать запись в правильном порядке недостаточно; современные диски имеют кэш большого объёма и меняют порядок записи для оптимизации производительности. Поэтому файловая система обязана явно сообщить диску о необходимости записать все журнальные данные на носитель перед созданием записи фиксации; если сначала будет создана запись фиксации, журнал может быть повреждён. Блокирующая система ввода-вывода ядра предоставляет такую возможность благодаря использованию механизма «шлагбаумов» (barriers); проще говоря, «шлагбаум» запрещает запись любых блоков, посланных после него, до того момента, как всё, что было прислано перед «шлагбаумом», будет перенесено на носитель. При использовании «шлагбаумов» файловая система может гарантировать, что всё, что находится на диске, целостно в любой момент времени. Отключая шлагбаум barrier=0, мы ускоряем операции записи на разделы.
barrier=0 нужно указать в /etc/fstab.

Для btrfs указывайте nobarrier.

LVM.
Если вы используете технологию LVM, то нужно указать в /etc/lvm/lvm.conf параметр issue_discards = 1.

Preload.
Демон, кешируюший обращения к файлам и ускоряющий IO вывод. В SSD диске нет вращающихся блинов и считывающих головок, то желательно в /etc/preload.conf изменить параметр и привести его к виду sortstrategy = 0. Этим самым вы прикажете не производить сортировку очереди запросов, так как для SSD это не имеет смысла. Перезапустите preload — sudo /etc/init.d/preload restart

Увеличим сброс грязных буферов vm.dirty_writeback_centisecs = 15000 в /etc/sysctl.conf.

У демонов журналирования rsyslogd или syslogd перед всеми путями к журналам поставим знак минус и заставим не делать sync после добавления одной строки в журнал. Демон ведения журналов syslog (а также идущий ему на смену — rsyslog) пишет журналы в каталоге /var/log/ и добавив одну строку делает операцию sync, которая сводит на нет кэш диска и более долгий сброс буферов. Можно изменить поведение демона и указать не делать sync после каждого добавления. Найдите файл конфигураций демона, обычно это /etc/syslog.conf или /etc/rsyslog.d/ и все пути вида /var/log/что-то-там/ измените, дописав знак минус («-«) перед путями.

В файл /etc/sysctl.conf в конец файла вставьте строку vm.swappiness = 10 и тем самым заставьте Ubuntu Linux больше занимать ОЗУ, чем swap. Как это достигается подробно расписано в Ускорении Ubuntu.

По умолчанию в Ubuntu Linux в качестве файлового планировщика используется CFQ, он старается минимизировать перемещения головок, но у SSD нет движущихся частей и CFQ не нужен. Нужно в файле /etc/default/grub добавить elevator=noop и получить строку, типа GRUB_CMDLINE_LINUX_DEFAULT=»quiet splash elevator=noop». Не забудьте sudo update-grub

Теперь перезагрузка вашего ПК и получите оптимизированную под плюсы и скрывающая минусы SSD систему Ubuntu Linux. Порадуйте себя скоростью SSD sudo hdparm -t /dev/ваш_диск_ssd

Советы SSD

1) Меньше пишешь на SSD, лучше.

2) Постоянная запись множества мелких файлов — самое большое зло для SSD. Запись на SSD производится блоками (вплоть до 128 Кб) и маленькие файлы вынуждают стирать блоки большего размера.

3) Располагать раздел подкачки на SSD можно и нужно. Работа с подкачкой характеризуются большим количеством чтения по сравнению с записью (40 к 1), и относительно большими объемами записи, так что пользы от гораздо более быстрого доступа к данным больше, чем вреда.

4) Если команда iotop часто показывает запись процесса в раздел, находящийся на SSD, сделай так, чтобы процесс туда писал реже или вообще не писал. Не бойся редкой записи — бойся постоянной, периодической записи. Смотри п.п 1.

5) Забудь про дефрагментацию, её больше для тебя не существует. Если увидел слово онлайн дефрагментация или дефрагментация на-лету, найди и выключи это.

6) В Ubuntu Linux кроме системного индексатора updatedb, остальные индексаторы хранят файлы-базы-данных в домашнем каталоге. Подумайте о необходимости этих индексаторов-поисковиков, если не нужны — отключайте/удаляйте.

Отличный видеоматериал, правда на английском языке, но всё понятно из самого видео и открытых окон как оптимизировать Linux для SSD.

Источник

Коротко и ясно о 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.

Скорость работы системы ЗНАЧИТЕЛЬНО ускорилась, точнее быстрее стали загружаться приложения, и быстрее загружается сама система.

Источник