Почему не нужен TRIM в серверах

- Поддерживает ли этот контроллер TRIM?
- Нет.
- А этот, за $1200?
- Нет.
- Какой ужас! Это заговор производителей! Как мне быть, получается, что мне нельзя подключать SSD, все будет плохо и сломается? Я читал в одном журнале, что TRIM должен быть всегда, это очень важно!
- TRIM не нужен.
- Как?!
А вот так. Для начала стоит разобраться с тем, как работает SSD, что такое сборка мусора, как работает TRIM и главное — почему он не нужен в серверах.
SSD отличается от HDD не только ограниченным ресурсом ячеек. Есть еще множество архитектурных особенностей.

Размеры секторов

Стандартный размер сектора для большинства блочных устройств (жестких дисков и систем хранения данных) равен 512 байт (на некоторых SAS/SCSI дисках возможны 520/528 байт для дополнительного контроля целостности данных). Последние несколько индустрия пытается перейти на секторы 4096 байт (4 КиБ), т.н. Advanced Format. Продвигается процесс медленно, все пока что остановилось на 512e, т.е. дисках с 4K-секторами внутри, но с эмуляцией 512 байт секторов для хоста. На дисках 512e могут возникать проблемы с производительностью: при необходимости записать блок данных размером меньше 4 КиБ контроллеру диска приходится считывать сектор, менять в нем данные и только потом записывать обратно. Для SSD ситуация с записью небольших блоков еще сложнее:
Контроллер SSD по-прежнему вынужден прикидываться блочным устройством с 512 байт сектором. Но внутри все сложнее: ячейки объединены в страницы размером, как правило, 4-8 КиБ, т.е. это минимально доступный для чтения или записи объем. Записать данные в ячейку/страницу просто так нельзя, для этого нужно предварительно выполнить операцию стирания, а стереть можно только целый блок, состоящий из нескольких десятков (например, 64 или 128, в зависимости от архитектуры SSD) страниц, т.е. минимально доступный для стирания блок может оказаться размером, например, в 512 КиБ.

Write amplification (усиление записи)

Данный термин означает соотношение между объемом данных, который фактически приходится записывать на флеш-память, и объемом, который пишет хост. Предположим, что у нас есть блок 512 КиБ с данными и нужно поменять небольшой фрагмент. Для модификации сектора в 512 байт контроллеру SSD приходится делать несколько операций (ситуация напоминает write penalty для RAID-5/6):

• прочитать весь блок в буфер
• модифицировать содержимое буфера
• стереть весь блок
• записать новое содержимое буфера

Т.е. для размера транзакции в 512 байт на SSD с размером блока страниц в 512 КиБ получаем write amplification = 1024 раза. Это не самым лучшим образом сказывается а) на производительности и б) ресурсе, который по-прежнему составляет несколько тысяч циклов перезаписи для MLC SSD.

Copy on write

Проблема усиления записи имеет простое решение: нужно стараться записывать данные в уже предварительно стертые блоки. На помощь приходит классический алгоритм copy-on-write, разновидности которого используются для оптимизации записи в RAID-DP у Netapp или в ZFS (только слоем выше — на уровне файловой системы).
Суть алгоритм copy-on-write заключается в записи в "выгодные" участки носителя, т.е. в случае SSD — на чистые (стертые) блоки. В нижеприведенном примере модифицируется содержимое страницы "B". Вместо чтения/стирания/записи всего большого блока достаточно лишь прочитать содержимое страницы, модифицировать ее и записать в другое место. При этом необходимо поменять указатель, чтобы те же LBA указывали на новое физическое место размещения данных.

В качестве дополнительного средства борьбы с write amplification большинство современных контроллеров SSD используют сжатие данных.

Где взять чистые блоки?

На новом SSD все блоки являются чистыми и готовыми к записи. Дальше есть резервная область, которая на самом деле, используется всегда, так как помимо оптимизации записи необходимо обеспечить еще и равномерность износа ячеек SSD.

TRIM

Как быть, если после непрерывной записи чистых блоков уже не осталось? Для можно каким-либо образом узнать, где на SSD находятся пользовательские данные, а где размещены невалидные данные, оставшиеся после удаления файлов. Собственно, этим и занимается TRIM. SSD, как и любое другое блочное устройство, ничего не знает, о том, какие именно данные на нем хранятся. ОС может взаимодействовать как со слоем файловой системы, так и с блочным устройством, т.е. после удаления файла ОС передает на SSD вместе с командой TRIM (или UNMAP для SCSI) список LBA, по которым находились удаленные данные. SSD получает в распоряжение блоки с невалидными данными, и эти блоки можно в дальнейшем использовать для записи.

Background garbage collection (фоновая сборка мусора)

Второй очевидный способ обнаружения невалидных данных — повторные запросы на запись от хоста по тем же LBA. Для хоста это выглядит, как перезапись одних и тех же секторов, но SSD все время старается писать в разные блоки. В вышеприведенной иллюстрации работы copy-on-write актуальные данные содержатся в новой странице "B'", после чего в исходной странице остаются невалидные данные.
Области с невалидными данными могут быть сильно фрагментированы, т.е. содержать ячейки с нужными данными. Остается последний шаг — дефрагментировать эти области, получив набор целых свободных блоков и выполнить их стирание.

Собственно, за все это и отвечает сборка мусора. "Правильные" SSD, рассчитанные на интенсивную запись, имеют достаточный over-provisiong (резервную область) в качестве "пространства для маневра" и эффективный контроллер с достаточным объемом кэша (разумеется, защищенного конденсаторами) для размещения метаданных и буферизации чтения/записи. Если контроллер не успевает быстро подготовить место для быстрой записи, то это неминуемо отразится на производительности, будет периодический рост задержек в несколько раз относительно среднего значения, как на данной картинке с www.storagereview.com:

TRIM и реальность

Для работы TRIM помимо выполнения множества условий (поддержка со стороны ОС и файловой системы) необходимо разобраться с другими слоями абстракции, например, RAID. Пересчитать адреса пришедшие на с TRIM на контроллер от хоста и раскидать их по отдельным дискам теоретически возможно, но никто (ни LSI, ни Adaptec by PMC) не торопится с реализацией. Причина проста — за пределами домашних систем или рабочих станций такая простая вещь, как удаление файла встречается крайне редко. В серверах, как правило, встречаются совершенно другие нагрузки, к которым TRIM не может иметь никакого отношения:

• Виртуализация. На физическом диске или томе RAID-контроллера лежит одна файловая система (VMFS/NTFS/XFS), а на ней - виртуальный диск в виде файла (который никуда не удаляется и даже не меняется в размере, если диск не тонкий), а внутри виртуального диска - другая ФС. Как, от кого и кому передавать TRIM в такой ситуации — совершенно непонятно.
• Предоставление блочного доступа. Это добавляет несколько уровней абстракции. Том->Раздел (или ФС + файл)->Таргет->Файловая система
• Файловый доступ. В организациях, как правило, никто не удаляет регулярно большое количество файлов. Такой сценарий встречается разве что при хранении временного медиа-контента, например, при рендеринге или перекодировании видео, а SSD тут совершенно не нужны. Файл-сервер обычно используется для долговременного хранения информации.
• Базы данных. Файл, который, опять-таки не удаляется, а лишь модифицируется и растет.

Заключение

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