Background garbage collection ssd что это

Background Garbage Collection

Процесс очистки памяти SSD накопителей от мусорной информации. При удалении файлов в операционной системе удаляется только информация о местоположении самого файла, сам же файл остается. Это приводит к снижению производительности SSD. Background Garbage Collection в фоновом режиме, то есть во время отсутствия запросов к диску от операционной системы, автоматически удаляет сами файлы. Для повышения эффективности работы Background Garbage Collection используются команды TRIM.

Введение в SSD. Часть 5. Контроллерная

В прошлых частях цикла мы рассказывали про историю накопителей, о применяемых интерфейсах и форм-факторах, а также про организацию на физическом уровне. Пятая же часть посвящена «мозгу» современного твердотельного накопителя.

Контроллер современного накопителя — маленький компьютер, который принимает стандартизированные команды и выполняет соответствующие действия с подконтрольным ему хранилищем. При этом внутреннее устройство контроллера может быть любым.

Контроллер — достаточно сложное устройство, которое в зависимости от предназначения диска выполняет различные задачи по управлению данными. Например, базы данных часто требуют от накопителя запись непосредственно в энергонезависимую память, минуя кэш, и в этом случае серверный SATA SSD будет быстрее, чем пользовательский NVMe. Из-за большой вариативности контроллеров не будем вдаваться в детали конкретных устройств, а поговорим об общих принципах работы современного твердотельного накопителя.

Особенности записи

Блоки и страницы в NAND-памяти. Источник
Хранилище твердотельного накопителя состоит из множества полевых транзисторов, соединенных друг с другом. При таком подходе чтение и запись выполняются страницами данных, размер которых обычно 4 КиБ. Таким образом, изменение одного бита на диске приводит к необходимости перезаписать всю страницу данных. Эта проблема называется усилением записи (Write Amplification).

Кроме того, твердотельные накопители не могут обновить данные в странице. Обновление страницы производится в четыре шага:

1. Чтение данных из страницы в буфер.
2. Изменение данных в странице.
3. Очистка страницы данных.
4. Запись обновленных данных из буфера.

Износостойкость

Выравнивание износа. Источник
Современные накопители построены на базе ячеек TLC, ресурс которых в разы меньше, чем у накопителей с ячейками SLC и MLC. Если какая-то программа в ОС будет постоянно перезаписывать маленький файл, а контроллер будет «наивно» обновлять одну страницу данных, то вскоре блок с этой страницей исчерпает ресурс. Исчерпание ресурса будет отображено в показателях накопителя, что неизбежно приведет к беспокойству системного администратора.

Во избежание сильного износа единичных блоков накопителя применяются технологии выравнивания износа (Wear Leveling). При этом обновление данных выполняется без очистки страницы накопителя и выглядит так:

1. Чтение данных из страницы в буфер.
2. Изменение данных в странице.
3. Запись обновленных данных из буфера в «чистую» страницу.
4. Старая страница помечается как «грязная».

Балансировка износа

В каком-то смысле производитель накопителей обманывает нас дважды. Первый раз использует десятичные приставки вместо двоичных: 480 ГБ — это 447 ГиБ. А второй раз, когда фактический объем накопителя больше, чем доступно пользователю. Часть объема зарезервирована производителем для внутренних нужд контроллера. Такой резерв называется запасной областью (spare).

Таким образом, у контроллера всегда есть немного свободного пространства, которое может быть использовано для внутренних процессов. Хотя точных данных нет, в различных источниках утверждается, что для контроллера резервируется от 7 до 28 % объема накопителя.

Увеличение объема зарезервированной области уменьшает доступный объем, но чаще всего повышает производительность диска. Для увеличения spare-области достаточно оставить часть накопителя неразмеченным. Однако если хочется экстрима и сделать все «по уму», то можно уменьшить объем видимого пользователю пространства через ключ -N утилиты hdparm.

Как бы то ни было, вернуть зарезервированную производителем область в собственное пользование не получится.

Процесс «сбора мусора». Источник
Помимо балансирования износа, в контроллерах в фоновом режиме часто проходит процесс «‎сбора мусора» (garbage collection). В ходе него с нескольких блоков собираются актуальные страницы и помещаются в один блок. Затем исходные блоки очищаются, так как в них не осталось страниц с данным.

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

Для решения этой проблемы в каждом из протоколов есть команда, позволяющая уведомить контроллер об удалении файла. Для NVMe — это deallocate, для SATA — TRIM, а для SCSI — unmap. Суть каждой их этих команд одинакова: пометить страницы с удаленным файлом как «грязные».

Контроллеру приходится постоянно беспокоиться о состоянии страниц хранилища. При этом напрашивается очевидная оптимизация: если операционная система пытается считать данные со страниц, на которых нет данных, то вместо операции чтения можно просто генерировать необходимое количество нулей.

Это легко подтверждается с помощью эксперимента. Проводим Secure Erase для накопителя и запускаем тесты на случайное чтение с глубиной очереди 64. Затем «забиваем» накопитель с помощью последовательной записи, желательно дважды. И повторяем тесты.

Размер блока	Чистый	Забитый
4M	3400 MiB/s	3376 MiB/s
8M	3399 MiB/s	3336 MiB/s

В наших тестах использовался SSD-накопитель Micron 7300 1.92 TB, подключенный по PCIe 3.0 x4. Третья версия PCI Express по четырем линиям способна пропускать 3940 МБ/с или 3757 МиБ/с. Мы, конечно, не достигли предела, но надо полагать, это из-за накладных расходов на протокол NVMe. Тем не менее, видно, что чтение с диска без данных «упирается» в предел 3400 МиБ/с. После заполнения диска на 15% результаты тестов стали хуже.

Несмотря на то, что контроллер накопителя всегда пытается сделать как лучше, иногда системному администратору стоит взглянуть на показатели диска своими глазами.

Показатели

Вне зависимости от интерфейса накопителя SSD имеют набор показателей состояния, которые могут быть считаны системным администратором. Для SATA-накопителей используются показатели S.M.A.R.T., которые не стандартизированы. Отсутствие стандарта приводит к появлению различных трактовок одного показателя.

Рассмотрим вывод утилиты smartctl на примере Intel S4510.

Для нашего диска интересны следующие параметры:

• 5 Reallocated_Sector_Ct — количество секторов с нулевым ресурсом.
• 187 Uncorrectable_Error_Cnt — количество ошибок, которые не удалось исправить при помощи кодов коррекции.
• 233 Media_Wearout_Indicator — процент износа диска.
• 243 NAND_Writes_32MiB — объем данных, который был записан на диск за все время.

С точки зрения износа исправного диска интересен показатель 233 Media_Wearout_Indicator, так как при достижении числа 1023 накопитель программно заблокируется и будет доступен в режиме только для чтения.

Показатели S.M.A.R.T — это особенность протокола SATA. Для NVMe-накопителей есть NVMe log, который также считывается программой smartctl. Аналогичный вывод можно получить с помощью команды nvme smart-log.

В выводе NVMe накопителя меньше непонятных показателей, но все равно есть место разночтениям. Легко предположить, что параметр percentage_used отвечает за объем занятого пользователем пространства на диске, но это не так. Этот параметр эквивалентен Media_Wearout_Indicator и обозначает износ накопителя.

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

Перепрошивка

О прошивке твердотельных накопителей задумываются нечасто. В лучшем случае после покупки «накатывают» свежую версию и забывают до конца жизни накопителя.

Как бы то ни было, обновления прошивки редко приносят какие-то значительные и заметные для пользователя нововведения. Прошивка, как и любое другое программное обеспечение, может содержать ошибки, в том числе критические. К счастью, это происходит редко, а потому нет надобности постоянно поддерживать актуальность прошивок на всех используемых накопителях.

Хотя NVMe можно перепрошить через команды fw-download и fw-commit, чаще всего обновление прошивки производится через утилиты, предоставляемые производителем накопителя. Во избежание потенциально деструктивных действий мы не будем публиковать точные команды, а порекомендуем обратиться к официальной инструкции от производителя.

Заключение

Контроллеры накопителей — сложные устройства, которые управляют не менее сложными процессами, которые проходят внутри твердотельных накопителей. Мы рассмотрели только самые интересные процессы в общих чертах.

Если вам хочется больше погрузиться в особенности работы с NVMe, рекомендуем статью про пространства имен NVMe.

Почему не нужен 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.

Как быть, если после непрерывной записи чистых блоков уже не осталось? Для можно каким-либо образом узнать, где на 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.

Garbage Collection and TRIM in SSDs Explained – An SSD Primer

DuraWrite, found in LSI ® SandForce ® Flash Storage Processors, produces similar benefits to the TRIM command whether or not TRIM is present. And when TRIM is present, DuraWrite creates more free space on the SSD than would be possible otherwise. Figure 4 illustrates.

Figure 4: DuraWrite versus non-DuraWrite SSD Controllers and the TRIM command.

In a standard SSD without DuraWrite (row 1 left), data pending deletion and the free space share the same space. There is less space available for GC, so the drive has to spend more time doing GC to efficiently use the available space. In a conventional SSD that supports TRIM (row 1 right), the data pending deletion becomes free space, and there is much more space available for GC. The more space available, the faster the SSD can write, so TRIM has a big impact on the SSD’s overall performance.

In an SSD with DuraWrite technology (row 2 left), less data is physically written to the drive in the first place, so there is more free space available for GC. In fact, the amount of space available in a non-TRIM environment is comparable to the space available in a TRIM environment on a conventional SSD. Writing less data frees up more GC space and improves the performance of the SSD. In the DuraWrite drive with the TRIM command (row 2 right), there is a massive amount of space available for GC. However, having significant amounts of free space does not linearly improve the performance of the SSD, because there are other bottleneck points in place.

There are many techniques used in the storage industry, such as data de-duplication, data compression, and data differencing. DuraWrite combines elements of these and similar technologies in order to reduce the amount of writes that must be passed through to the flash.

Therefore, an SSD with DuraWrite in a system that doesn’t support TRIM behaves much like a regular SSD that does support TRIM. It is also possible to use DuraWrite in a RAID environment and get the benefits of having the TRIM command without the RAID drivers having to support TRIM.

BACKGROUND VS FOREGROUND GARBAGE COLLECTION

The final question is when to perform GC. There is debate in the industry between doing background (or idle-time) GC, and foreground (or standard) GC.

It seems like a good idea to do GC in the background, when the host isn’t demanding something of the SSD. It seems reasonable to perform housekeeping like GC when the SSD isn’t otherwise busy, so it can be ready with optimized blocks when the OS writes a new file or changes a file.

However, there are two problems with this. First, background GC can potentially relocate all of the currently valid data on the SSD, when in fact some of that data may be invalid e.g., in temporary files, or may otherwise soon be deleted by the OS. If blocks with invalid data are garbage collected in the background, the SSD will be rewriting a lot of data that won’t be needed in a short time, directly leading to unnecessary wear on the SSD and reduced endurance.

Background GC is used primarily with SSDs whose write speed is slow, because it reduces the amount of GC that must be done in the foreground, and therefore allows the SSD to perform a bit faster during writes. That is until the incoming host data traffic catches up with the freed space from the background GC at which time is it forced to perform it real-time.

Foreground GC, on the other hand, results in data being rewritten only when the free space will be immediately needed. Foreground GC thus avoids performing GC on data that will soon be invalid, and it reduces overall wear on the drive. This requires an SSD that has very high write speeds. LSI SandForce Flash Storage Processors have an architecture that enables the fastest possible foreground GC.

The difference between background and foreground GC is less obvious in consumer-level drives where there tends to be a lot of idle time and endurance isn’t as critical, but it is more obvious in enterprise-class drives, where writes occur all the time and duty cycles are longer.

LSI SandForce Flash Storage Processors use optimized GC techniques, so they can perform foreground (or real-time) GC better than the other SSD controllers. If the SSD also writes less data overall with the DuraWrite technology, there is less data to rewrite during GC, and the SSD performs even better.

As we have seen, GC is a necessary function of all SSDs. The decisions to use foreground or background GC as well as the use of the TRIM command impact an SSD’s performance, write amplification, and endurance. These factors should be carefully considered when designing SSDs or selecting one for a computer system.

In case this article has reached you through one of the many search engines, we should mention that this is the third in our series of SSD Primer articles meant to help us all along in our understand of solid state drives.