Background Garbage Collection
Процесс очистки памяти SSD накопителей от мусорной информации. При удалении файлов в операционной системе удаляется только информация о местоположении самого файла, сам же файл остается. Это приводит к снижению производительности SSD. Background Garbage Collection в фоновом режиме, то есть во время отсутствия запросов к диску от операционной системы, автоматически удаляет сами файлы. Для повышения эффективности работы Background Garbage Collection используются команды TRIM.
Методики очистки памяти от мусора, применяемые в Kingston, для повышения производительности твердотельных накопителей при использовании в клиентских системах
SSD создаются на базе современных контроллеров, управляющих флеш-накопителями NAND. Kingston использует в отдельных SSD контроллеры на основе LSI® SandForce для повышенной надежности и производительности. Эти контроллеры используют собственные технологии для выполнения очистки памяти (Garbage Collection).
При удалении файлов операционной системой (например Windows) ОС отмечает в своей внутренней таблице файлов, что файл удален. На жестких дисках (HDD) такие недействительные данные сохраняются и могут быть напрямую перезаписаны системой для хранения новых данных.
Устройства на основе памяти NAND не могут перезаписывать данные, уже находящиеся на накопителе. Они должны выполнить цикл программирования-стирания; для записи в уже использованный блок данных контроллер SSD сначала должен скопировать все действительные данные (которые еще используются) и записать их в пустые страницы другого блока, очистить все ячейки в текущем блоке (от действительных и недействительных данных), а затем начать запись новых данных в уже очищенный блок. Этот процесс называется очисткой памяти. Современные ОС также поддерживают команду TRIM, с помощью которой ОС сообщает SSD об удалении файлов, чтобы SSD мог лучше управлять процессом очистки памяти и восстанавливать это пространство заранее без сохранения и перемещения недействительных данных.
SSD компании Kingston с контроллерами LSI SandForce выполняют высокоэффективную приоритетную очистку памяти, быстро подготавливая блоки для удаления в реальном времени, и не выполняют фоновую очистку памяти, приводящую к предварительному перемещению данных, которые вскоре могут быть удалены пользователем. Методика приоритетной очистки памяти обеспечивает повышенную надежность и производительность SSD. Кроме того, приоритетная очистка памяти максимально повышает преимущества режимов ожидания с низким энергопотреблением, отключая накопитель, когда система не осуществляет доступ к SSD, в то время как процесс фоновой очистки памяти прерывает ожидание, поскольку перемещает данные для подготовки новых блоков до того, как они потребуются.
Kingston провел тестирование с помощью утилиты Anvil, выполняющей циклы заполнения SSD данными, удаления всех данных и повторного заполнения накопителя данными. Мы протестировали эту утилиту с TRIM и без TRIM (система без TRIM эмулировалась с помощью SSD KC300 на сервере с картой RAID, в которой команда TRIM не пропускалась контроллером RAID, или с помощью SSD Kingston на платформах Apple Mac).
Результаты показывают, что производительность SSDNow обеспечивает меньшее время заполнения накопителя и повторного заполнения после полного удаления файлов; это доказывает эффективность очистки памяти таких SSD: На левой оси указано время заполнения накопителя (в секундах; чем ниже, тем лучше), на нижней оси указаны 10 последовательных запусков с TRIM и без TRIM. KC300 не только обеспечивает минимальное время заполнения и повторного заполнения данными, его производительность также постоянна в течение всех 10 запусков со включенным и выключенным TRIM. SSD KC300 также поддерживают технологию DuraWrite с функцией уменьшения объема данных, которая тоже повышает надежность и производительность (Дополнительную информацию см. в техническом обзоре DuraWrite по адресу kingston.com/ssd.)
SSD Samsung PM893 (240 Гб, 2.5″, SATA, 3D TLC (Triple Level Cell))
Накопитель SSD 240 Gb SATA 6Gb/s Samsung PM893
SSD 2.5″, SSD с интерфейсом SATA 6Gb/s , SSD для серверов баз данных
Артикул: #542423 Сравнить
Для начала стоит разобраться с тем, как работает 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.