# Solid State Drives (Русский)

## Введение

Твердотельные накопители (SSD) не достаточно просто подключить чтобы они заработали должным образом. Необходимо учитывать некоторые специфичные вещи для достижения оптимальной производительности, такие как выравнивание разделов, выбор файловой системы, поддержка TRIM и т. д. Статья пытается охватить общую информацию и ключевые понятия, чтобы позволить пользователям получить максимальную отдачу от твердотельных дисков под Linux. Рекомендуется прочесть статью полностью перед тем, как следовать рекомендациям.

Обратите внимание: Хотя статья и предназначена для пользователей Linux, большая часть информации может относиться также и к другим операционным системам, таким как BSD, Mac OS X или Windows.

### Преимущества перед HDD

- Высокая скорость чтения. В 2-3 раза быстрее современных HDD (7200 об/мин на интерфейсе SATA2).
- Устойчивая скорость чтения. Скорость чтения не уменьшается на протяжении всего объёма диска, тогда как производительность HDD падает при перемещении головок от края пластин к центру.
- Минимальное время доступа. Приблизительно в 100 раз быстрее HDD. Например, 0,1 мс для SSD против 12-20 мс для HDD.
- Высокая степень надежности.
- Отсутствие движущихся частей.
- Минимальный нагрев.
- Минимальное потребление энергии. 1-2 Вт для SSD против 10-30 Вт для HDD (в зависимости от об/мин).
- Легкие. Идеальное решение для ноутбуков.

### Недостатки

- Цена за единицу объёма (десятки долларов за ГБ на SSD, тогда как стоимость ГБ для HDD измеряется копейками).
- Ёмкость представленных моделей SSD намного ниже оной для HDD.
- Большие ячейки памяти требуют различных оптимизаций файловых систем. Низкий уровень доступа скрыт за контроллером, в то время как современные ОС могли бы использовать низкий уровень для собственных оптимизаций.
- Разделы и файловые системы требуют специальных оптимизаций. Размер страницы и размер стираемой страницы автоматически не определяется.
- Ячейки изнашиваются. MLC-ячейки, произведённые по 50нм техпроцессу, могут выдерживать до 10 тысяч циклов записи; 35нм обычно выдерживают всего 5000 циклов, а 25нм — 3000 (чем меньше техпроцесс, тем больше плотность и ниже цена). Если участки записи распределены соответствующим образом, не слишком малы и верно выровнены, это увеличивает срок жизни ячеек пропорционально общему объёму.
- Сложные прошивки и контроллеры. В них часто встречаются баги. Современные потребляют мощность, сравнимую с HDD. Они реализуют подобие журнально-структурированной файловой системы со сборкой мусора, переводят команды SATA, изначально предназначенные для HDD; некоторые реализуют сжатие на лету. Также контроллер распределяет циклы записи по всей области диска для предотвращения быстрого износа ячеек, объединяет несколько команд записи мелких данных в одну, опять же, для увеличения продолжительности жизни диска. Наконец, "мозги" твердотельных накопителей перемещают ячейки с данными по диску, чтобы те со временем не потеряли содержимое.
- Может падать производительность в зависимости от заполненности диска. Не все производители реализовывают сборку мусора достаточно хорошо, поэтому фрагментированное свободное пространство не всегда объединяется в целые ячейки.

## На что обращать внимание перед покупкой

Есть несколько ключевых особенностей, на которые стоит обратить внимание до покупки SSD.

### Ключевые особенности

- Родная поддержка TRIM. Это жизненно необходимая функция для продления срока службы SSD и предотвращения уменьшения производительности операций записи от времени.
- Также ключом является покупка SSD верного объема. Для эффективной работы разделы во всех файловых системах должны быть заполнены не более, чем на 75%.

### Обзоры

Обзоры не такие уж полные, но основные ключевые особенности они освещают.

- SSD Anthology (history lesson, a bit dated)
- SSD Relapse (refresher and more up to date)
- One user's recommendations
- Enabling and Testing SSD TRIM Support Under Linux

## Советы по увеличению производительности SSD

### Параметры монтирования

Существует несколько ключевых параметров монтирования, используемых в `/etc/fstab` для разделов на SSD.

- noatime - Во время чтения файлов не будет обновляться поле atime файловой системы, указывающее время последнего доступа к файлу. Важность данного параметра в том, что он убирает необходимость системы производить "ненужные" операции записи когда файл всего-навсего необходимо прочитать. Т. к. эти операции записи могут быть достаточно интенсивными при чтении большого количества файлов, отключение может дать неплохой прирост производительности и срока жизни. Заметьте, что информация о времени последней записи файла будет по-прежнему обновляться каждый раз, когда файл будет изменён.
  - Однако, эта опция может вызвать проблемы с некоторыми программами, такими как Mutt, т. к. время доступа к файлу станет меньше, чем время изменения, что вызовет проблемы в работе. Использование опции relatime вместо noatime позволит быть уверенным, что поле atime никогда не станет меньше, чем время изменения.
- discard - Параметр discard включает команду TRIM для ядер версии 2.6.33 и выше. Не работает с файловой системой ext3; если всё же он включен на ext3, корневой раздел будет смонтирован только для чтения.

    /dev/sda1 / ext4 defaults,relatime,discard 0 1
    /dev/sda2 /home ext4 defaults,relatime,discard 0 1

Важно: Пользователь должен убедиться ещё ДО попытки монтирования раздела с опцией `discard`, что он работает на ядре версии 2.6.33 или выше, а также, что его SDD поддерживает TRIM. Иначе можно потерять данные!

### Включение Discard через tune2fs

Можно также статически установить флаг поддержки TRIM с помощью tune2fs или при создании раздела.

    # tune2fs -o discard /dev/sdXY

или

    # mkfs.ext4 -E discard /dev/sdXY

Обратите внимание: После установки этой опции, команда mount НЕ будет показывать флаг discard в списке смонтированных ФС, даже если флаг указан явно в опциях командной строки несмотря на добавленный через tune2fs или mkfs. См. соответствующую тему в обсуждении: https://bbs.archlinux.org/viewtopic.php?id=137314

### I/O планировщик

Рассмотрим переход со стандартного CFQ планировщика (Completely Fair Queuing) начиная с ядра 2.6.18 к планировщикам NOOP или Deadline. Последние два обеспечивают повышение производительности SSD. Планировщик NOOP, например, реализует простую очередь входящих запросов чтения/записи без их переупорядочивания или группировки. На SSD, в отличие от HDD, время доступа одинаково для всех секторов, поэтому изменение порядка запросов не имеет смысла.

Больше информации о планировщиках смотрите здесь: Linux Magazine article, Phoronix benchmark и FS#22605.

Arch по умолчанию использует планировщик CFQ. Убедиться в этом можно, выведя содержимое файла `/sys/block/sdX/queue/scheduler`:

    $ cat /sys/block/sdX/queue/scheduler
    noop deadline [cfq]

Планировщик, используемый в данный момент, выделен квадратными скобками.

##### Параметр ядра (в системе только SSD)

Если в системе нет других типов накопителей кроме SSD, планировщик включается параметром ядра `elevator=noop`. Для дополнительного ознакомления смотрите Kernel parameters.

##### Использование виртуальной ФС sys (для нескольких типов накопителей)

Этот метод используется, когда в системе установлено несколько физических накопителей разных типов (например, одновременно SSD и HDD). Добавьте следующую строку в `/etc/rc.local`:

    echo noop > /sys/block/sdX/queue/scheduler

где X — буква вашего SSD устройства.

Из-за вероятности того, что udev может назначить дискам разные ноды в `/dev/` после обновления ядра, пользователь должен убедиться, что планировщик NOOP во время загрузки применился к нужному устройству. Один из способов заключается в использовании идентификатора диска для определения его ноды в `/dev/`. Для этого используйте данный кусок кода вместо строки выше и добавьте его в `/etc/rc.local`:

    declare -ar SSDS=(
      'scsi-SATA_SAMSUNG_SSD_PM8_S0NUNEAB861972'
      'ata-SAMSUNG_SSD_PM810_2.5__7mm_256GB_S0NUNEAB861972'
    )

    for SSD in "${SSDS[@]}" ; do
      BY_ID=/dev/disk/by-id/$SSD

      if [[ -e $BY_ID ]] ; then
        DEV_NAME=`ls -l $BY_ID | awk '{ print $NF }' | sed -e 's/[/\.]//g'`
        SCHED=/sys/block/$DEV_NAME/queue/scheduler

        if [[ -w $SCHED ]] ; then
          echo noop > $SCHED
        fi
      fi
    done

где `SSDS` — массив Bash, содержащий идентификаторы всех SSD-дисков. Идентификаторы перечислены в директории `/dev/disk/by-id/` в виде символьных ссылок на соответствующие ноды в `/dev/`. Чтобы увидеть ссылки и то, куда они указывают, выполните команду:

    ls -l /dev/disk/by-id/

##### Использование udev как для одного накопителя, так и для нескольких разных

Хотя вышеописанные методы будут работать без проблем, ниже представлено также довольно надёжное решение. Следует отметить, что с переходом на systemd, файл rc.local больше не существует. Следовательно, было бы предпочтительнее использовать систему, которая отвечает за устройства, в первую очередь для реализации планировщика. В нашем случае это udev, и чтобы осуществить задуманное, всё что нам нужно — простое udev-правило.

Создайте файл в директории /etc/udev/rules.d с именем, например, '60-schedulers.rules'. Запишите в него следующие строки:

    # установка планировщика deadline для SSD
    ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

    # установка планировщика cfq для HDD
    ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"

Конечно же вы можете заменить deadline/cfq любыми другими планировщиками. Изменения вступают в силу после перезагрузки. Чтобы проверить сработало ли правило, выполните команду

    $ cat /sys/block/sdX/queue/scheduler   #где X — буква физического накопителя

Обратите внимание: Имейте в виду, CFQ является планировщиком по умолчанию, так что второе правило на самом деле не нужно, если вы пользуетесь стандартным ядром. Также в примере имя правила начинается с числа 60, т. к. это число udev использует для своих строгих правил именования. Блочные устройства в этом диапазоне чисел могут модифицироваться, и это безопасная позиция для данного правила. Однако, правило может называться как угодно, при этом оканчиваться на '.rules'. (Источник: falconindy и w0ng на своём блоге)

### Разделы подкачки на SSD

Можно размещать раздел подкачки на SSD. Но с другой стороны, современные компьютеры, имеющие более 2 ГБ оперативной памяти, используют раздел подкачки очень редко. Заметным исключением являются системы, которые используют спящий режим. Следующая оптимизация для SSD уменьшает "swappiness" системы, чтобы избежать записей подкачки:

    # echo 1 > /proc/sys/vm/swappiness

Или можно просто изменить файл `/etc/sysctl.d/40-swappiness.conf` как рекомендуется в вики-статье Maximizing Performance:

    vm.swappiness=1
    vm.vfs_cache_pressure=50

### Очистка ячеек памяти SSD

В некоторых случаях, пользователь может полностью сбросить ячейки SSD в состояние, подобное моменту покупки нового накопителя, таким образом добиться заводской производительности. Скорость записи уменьшается со временем даже с поддержкой TRIM. TRIM работает только с удалением файлов, но не с перемещением и инкрементальными сохранениями.

Сброс ячеек легко выполнить за 3 шага, описанных в вики-статье SSD Memory Cell Clearing.

## Советы для уменьшения операций чтения/записи

Основной идеей долговечного использования SSD является перенос интенсивных операция ввода/вывода в оперативную память или HDD, в основном из-за большого размера блока очистки (512 КиБ в некоторых случаях).

Обратите внимание: 32ГБ SSD с посредственным 10-кратным показателем write amplification, стандартными 10000 циклами чтения/записи и 10ГБ записей в день дают 8 лет жизни. Также, дольше живут диски с наибольшими объемами и современными контроллерами, которые имеют меньший показатель write amplification.

Используйте команду `iotop -oPa` и отсортируйте по количеству записей, чтобы увидеть сколько пишется на диск.

### Продуманная схема разделов

Если в системе установлены одновременно оба типа дисков (HDD и SSD), то рекомендуется монтировать раздел `/var` на HDD, чтобы продлить жизнь SSD, избежав на нём множества операций чтения/записи.

Если же SSD является единственным диском в системе, и нет возможности использовать его совместно с HDD, разумно так же выделить отдельный раздел для `/var`, чтобы в дальнейшем при возникновении ошибки было легче восстановить систему. Например, если программа использовала всё доступное пространство в `/`, какой-либо лог превысил все разумные размеры, и т. п.

### Опция монтирования noatime

Монтируйте разделы SSD с опцией `noatime`. См. раздел Параметры монтирования.

### Расположите часто используемые файлы в оперативной памяти

#### Профили браузеров

Довольно просто можно перенести профили браузеров, таких как chromium, firefox, opera, и т.д. в оперативную память через tmpfs и использовать rsync для синхронизации с копиями на диске. Таким образом можно так же заметно сократить количество операций чтения/записи.

В AUR есть несколько пакетов для автоматизации этой операции, например profile-sync-daemon.

#### Другие файлы

По этой же вышеописанной причине можно расположить в оперативной памяти раздел `/srv/http` (если запущен web-сервер). Аналогом profile-sync-daemon здесь будет anything-sync-daemon, который позволяет определить любую директорию для синхронизации с оперативной памятью.

Важно: Не пытайтесь добавлять /var/log в anything-sync-daemon. Systemd очень разозлится на это.

### Компиляция в tmpfs

Перенос интенсивной компиляции в `/tmp` — отличная идея продления срока жизни диска. Если у вас имеется более 4ГБ оперативной памяти, строку tmp из `/etc/fstab` нужно изменить, чтобы раздел использовал больше половины доступной памяти, через параметр `size=`, т. к. `/tmp` при компиляции растёт очень быстро.

Пример для машины с 8ГБ оперативки:

    tmpfs /tmp tmpfs nodev,nosuid,size=7G 0 0

### Отключение журналирования ФС

Использование журналируемых ФС типа ext3 или ext4 с отключенным журналом тоже сократит количество записей на SSD. Очевидным недостатком этого будет являться потеря данных при неудачном размонтировании (резкое отключение питания, блокировка ядра и т. д.). Однако, Ted Tso выступает в защиту журналирования на современных SSD, т. к. по его тестам оно незначительно влияет на количество записей в большинстве случаев:

Количество записанных данных (в мегабайтах) на ФС ext4 с параметром noatime.

операция | с журналом | без журнала | разница
--- | --- | --- | ---
git clone | 367.0 | 353.0 | 3.81 %
make | 207.6 | 199.4 | 3.95 %
make clean | 6.45 | 3.73 | 42.17 %

"Результаты показали, что записанный объём при работе с большим количеством мета-данных почти в 2 раза выше, чем реальный размер файлов. Это ожидаемо, т. к. все изменения в блоках мета-данных сначала пишутся в журнал, и транзакция журнала сбрасывается перед тем, как мета-данные будут записаны в конечное положение на диск. Однако же, для обычных задач, где данные пишутся сразу за мета-данными, разница в лишних операциях записи минимальна."

Обратите внимание: Пример make clean из таблицы выше показывает важность переноса компиляции в tmpfs как рекомендовано в предыдущем разделе!

### Выбор файловой системы

Существуют различные варианты файловых систем на выбор, включая Ext2/3/4, Btrfs, и т. д.

#### Btrfs

Поддержка Btrfs включена в ядро с версии 2.6.29. Некоторые считают, что она является не достаточно стабильной для повседневного использования, в то время как есть и явные сторонники этого потенциального преемника ext4. Рекомендуется прочитать статью Btrfs для дополнительного ознакомления.

#### Ext4

Ext4 — ещё одна файловая система, поддерживающая SSD. Считается стабильной и пригодной для повседневного использования с версии ядра 2.6.28. В отличие от Btrfs, ext4 не умеет автоматически определять тип диска; пользователь сам должен явно включить поддержку команды TRIM, используя параметр монтирования `discard` в fstab (или командой `tune2fs -o discard /dev/sdaX`). См. официальную документацию ядра для подробного ознакомления c ext4.

## Тестирования производительности SSD

См. статью SSD Benchmarking с данными о тестировании и результатами некоторых SSD.

## Обновление прошивок

### OCZ

Для дисков компании OCZ имеется утилита командной строки для Linux (i686 и x86_64) на официальном форуме или в AUR ocztoolbox

## См. также

- Discussion on Reddit about installing Arch on an SSD

Categories:

- Storage (Русский)
- Русский