Использование ALT Linux на твердотельных дисках
SSD (Solid State Drive, твердотельный накопитель) — перспективный вид постоянной памяти, отличающийся высокой скоростью и низкой латентностью доступа, который уже пригоден для использования в десктопных и серверных задачах.
Несмотря на эти достоинства и совместимость с обычными SATA HDD по интерфейсу большинства моделей, начинка радикально отличается по поведению и без учёта этой разницы можно получить снижение производительности и сокращение срока службы.
Выравнивание разделов
Вкратце — как и для HDD с размером сектора более 512 байт или страйповых RAID, для получения разумной производительности необходимо учитывать размер физического блока [1] при разбиении устройства на разделы. Может быть достаточно отделить первые 1—4 [2] двоичных (sic!) мегабайта и начинать первый раздел с 2048-го или 8192-го сектора размером в 512 байт; текущий fdisk сделает это автоматически, инсталер 6.0+ — тоже.
Минимизация записи
Количество циклов перезаписи для flash-памяти ограничено, поэтому при всех предпринимаемых производителями мерах по wear leveling стоит по возможности снизить запись на разделы, размещённые на SSD-накопителе (особенно мелкоблочную случайного характера, для которой ожидаема высокая степень write amplification).
временные файлы
Рекомендуется /tmp на tmpfs (по умолчанию в 4.0+) совместно с pam_mktemp. Можно обдумать отключение дискового кэша браузера.
журналы
- десктоп: рекомендуется отключить ( chkconfig syslogd off; service syslogd stop )
- сервер: стоит пересмотреть конфигурацию syslog (см. /etc/syslog.* ).
своп
При достаточном количестве RAM можно обдумать/проверить работу без раздела/файла подкачки (либо вынести его на HDD).
Настройки
block layer
Можно выставить планировщик ввода-вывода noop или deadline [3] , добавив в /etc/sysfs.conf ( sysfsutils ) строку
block/sda/queue/scheduler = deadline
echo noop > /sys/block/sda/queue/scheduler
VFS
Рекомендуется добавить в /etc/sysctl.conf строку
файловые системы
Некоторые ФС уже обзавелись [4] поддержкой SSD, которую стоит задействовать — сперва проверив при помощи mount -o remount,option=value вручную и затем аккуратно зафиксировав в /etc/fstab .
В последнее время считается, что рекомендуемым вариантом является периодическое выполнение команды fstrim -a , а не применение опций ФС для немедленной отработки TRIM по освобождаемому пространству. Одновременное применение опций ФС и fstrim не имеет смысла.
общие
ext4
- желательно: data=writeback,delalloc,nobarrier
- при поддержке TRIM накопителем: discard
- возможно [6][7] : stripe=1024,commit=NN,max_batch_time=NNNNN,min_batch_time=NNNN
для использования опции монтирования data=writeback для корневой файловой системы (/) нужно также добавить в параметры загрузки ядра:
btrfs
- ssd (btrfs автоматически применяет опцию ssd, если видит SSD)
- при поддержке TRIM накопителем: discard
Примечания
- ↑ . даже если про него железка смело врёт, что «512 bytes»!
- ↑ см. тж. flashbench и здесь
- ↑deadline вроде как больше подходит для контроллеров недорогих SSD, которые могут «захлебнуть» запись; noop чуть дешевле по CPU
- ↑ Linux 2.6.33++
- ↑ также включаетnodiratime
- ↑ почитайте man mount и подгоните под свою ситуацию!
- ↑ замечено, что как минимум под 2.6.39-pure-emerald-alt6 max_batch_time получает значение min_batch_time, см. /proc/mounts
Ссылки
обзорные
предметные
Коротко и ясно о 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.
Скорость работы системы ЗНАЧИТЕЛЬНО ускорилась, точнее быстрее стали загружаться приложения, и быстрее загружается сама система.