Как SSD умирает медленно: wear leveling простыми словами

MAATRIX

SSD не «вдруг умирает» — если вам так кажется, скорее всего вы просто не смотрели на его SMART до последнего дня. У флеш-памяти есть предсказуемый ресурс на запись, и контроллер диска всю жизнь занимается тем, что честно распределяет износ по ячейкам, а не прячет его. Разберём, как это устроено внутри и как за этим следить, чтобы диск на сервере не преподнёс сюрприз в проде.

Почему у флеш-памяти вообще есть ресурс

Ячейка NAND-флеш хранит заряд в изолированном плавающем затворе, и чтобы записать в неё новое значение, контроллер сначала обязан стереть блок целиком, а потом уже писать. Само стирание — это довольно грубая операция: через тонкий диэлектрик прогоняется напряжение, чтобы вытолкнуть заряд, и каждый такой цикл чуть-чуть повреждает изолирующий слой. Постепенно диэлектрик «изнашивается», начинает подтекать заряд, ячейка хуже держит записанное значение и в какой-то момент контроллер решает, что доверять ей больше нельзя.

Отсюда и берётся паспортный ресурс — количество циклов «стереть-записать» (program/erase cycle, P/E cycle), которое гарантированно выдерживает ячейка данного типа памяти. Дальше вступает разница между типами NAND:

• SLC (1 бит на ячейку) — самый живучий, но дорогой и малой ёмкости, сейчас почти не встречается в потребительских и серверных дисках напрямую.
• MLC (2 бита на ячейку) — баланс ресурса и цены, раньше был стандартом для серверных дисков.
• TLC (3 бита на ячейку) — основной массовый вариант сейчас, ресурс на ячейку ниже, но плотность и цена лучше.
• QLC (4 бита на ячейку) — самая высокая плотность и самая низкая цена за гигабайт, но и самый скромный ресурс на ячейку из всех.

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

Как контроллер распределяет износ: wear leveling

Если бы операционная система писала на диск «в лоб», как на бумагу, одни и те же логические адреса (например, таблица метаданных файловой системы, которая перезаписывается непрерывно) убивали бы одни и те же физические ячейки за недели, пока остальной диск оставался бы почти нетронутым. Именно для этого между операционной системой и физической памятью стоит FTL — Flash Translation Layer, часть прошивки контроллера, которая держит таблицу соответствия логических адресов (LBA) физическим блокам NAND.

Wear leveling — это алгоритм FTL, который следит, чтобы циклы стирания размазывались по всем блокам диска примерно поровну, а не концентрировались там, куда чаще всего просит писать система:

• Динамический wear leveling — контроллер при каждой новой записи выбирает под неё не тот же самый физический блок, а тот, что изнашивался меньше остальных среди свободных. Логический адрес остаётся прежним для системы, но физически данные каждый раз «переезжают» в новое место.
• Статический wear leveling — сложнее: контроллер время от времени переносит даже редко изменяемые «холодные» данные (файлы, которые лежат месяцами и не трогаются) в сильно изношенные блоки, а из них забирает малоизношенные под текущую запись. Без этого шага блоки с холодными данными вообще не участвовали бы в ротации и не помогали бы выравнивать износ.

Побочный эффект такой перекладки данных — write amplification, усиление записи: чтобы физически записать 1 МБ пользовательских данных, диску иногда приходится реально перезаписать заметно больше, потому что попутно переносятся соседние действительные данные из блока, который готовится к стиранию (garbage collection). Отсюда правило: чем больше на диске свободного места (оверпровижининг), тем контроллеру проще находить малоизношенные блоки и тем меньше реальное усиление записи — это одна из причин, почему серверные NVMe держат заметный процент ёмкости в резерве, не отдавая его пользователю.

TBW и DWPD: как читать паспортный ресурс

В характеристиках любого приличного SSD есть два числа, которые прямо говорят о ресурсе на запись:

• TBW (Terabytes Written) — сколько терабайт производитель гарантирует записать на диск за весь срок гарантии, прежде чем откажется признавать деградацию гарантийным случаем. Это не «сколько диск проживёт», а обязательство производителя в рамках гарантии.
• DWPD (Drive Writes Per Day) — то же самое, но выраженное как «сколько раз можно перезаписать весь объём диска целиком за день» на протяжении гарантийного срока (обычно 3 или 5 лет). DWPD удобнее для сравнения дисков разной ёмкости: 1 DWPD на 5 лет для диска в 2 ТБ означает примерно 3650 полных перезаписей всего объёма за срок гарантии.

Оба параметра считаются производителем по конкретному профилю нагрузки (обычно это условный «типичный» микс чтения и записи), поэтому не воспринимайте TBW как физический предел, после которого диск немедленно превращается в кирпич — это скорее порог, до которого производитель ручается за характеристики. Диски для баз данных и активной записи в характеристиках почти всегда указывают DWPD (часто 1-3 и выше), а диски под архивные и read-intensive задачи — в основном TBW при DWPD около 0.3-0.5, и это осознанный компромисс производителя, а не недоработка.

Важный нюанс: TBW и DWPD считаются от объёма данных, которые реально дошли до записи в NAND, то есть уже с учётом write amplification конкретного контроллера — сравнивать эти цифры между дисками разных производителей напрямую стоит с осторожностью, потому что методика подсчёта не всегда идентична.

Почему деградация предсказуема, а не внезапна

Отказ SSD из-за исчерпания ресурса записи — это, по сути, статистика, а не единичное событие. Контроллер помечает блок «плохим» и выводит его из ротации задолго до того, как он начинает реально терять данные — как только количество ошибок коррекции (ECC) при чтении блока превышает безопасный порог. У диска в резерве всегда есть spare area — набор блоков, не видимых пользователю, которые как раз и заменяют выбывшие из строя.

Пока в резерве есть свободные блоки, диск просто медленно «худеет» с точки зрения контроллера: оставшийся резерв сокращается, а внешне для пользователя ничего не меняется — ни объём, ни скорость заметно не проседают. Реальная проблема начинается, когда резервных блоков почти не остаётся: тогда контроллер вынужден переводить диск в защитный режим — чаще всего read-only, чтобы не потерять уже записанные данные, — либо диск начинает возвращать ошибки записи. Это и есть тот самый «внезапный» отказ, который на самом деле готовился месяцами и был виден в SMART заранее, просто никто туда не смотрел.

Отдельно стоит сказать про отказы, которые с износом NAND не связаны: выход из строя контроллера, проблемы с питанием, баги прошивки. Такие отказы действительно бывают внезапными и не предсказываются мониторингом ресурса — от них не спасает ничего, кроме резервных копий и RAID. Про то, как эти механизмы уже работают на серверах, есть отдельный разбор — RAID на сервере: уровни и как выбрать и замена диска без простоя на RAID.

Как посмотреть реальный износ через SMART

На практике достаточно двух утилит в зависимости от типа диска.

Для NVMe-дисков — встроенная команда nvme-cli:

nvme smart-log /dev/nvme0

В выводе смотрите на несколько ключевых полей:

• percentage_used — главный индикатор. Это не «процент заполнения диска», а расчётная доля использованного ресурса записи относительно паспорта производителя. 0% — диск свежий, 100% — производитель считает ресурс исчерпанным (это не значит, что диск немедленно откажет, но гарантийные обязательства по износу на этом заканчиваются).
• data_units_written — сколько единиц данных реально записано за всё время (обычно в блоках по 512000 байт — переведите в терабайты и сравните с TBW из паспорта).
• media_errors — количество ошибок в самой флеш-памяти, которые не удалось скорректировать ECC. В норме должно быть 0.
• critical_warning — битовая маска критических предупреждений; если не 0 — читайте расшифровку конкретного бита, это может быть как раз превышение порога износа.

Для SATA/SAS SSD — smartctl из пакета smartmontools:

smartctl -a /dev/sda

Здесь названия атрибутов отличаются от производителя к производителю, но чаще всего встречаются:

• ID 177 (Wear_Leveling_Count) или ID 233 (Media_Wearout_Indicator) — аналог percentage_used у NVMe, обычно нормализованное значение от 100 (новый) до 1 (ресурс исчерпан) — но проверяйте по документации конкретного производителя, направление шкалы не всегда одинаковое.
• ID 241 (Total_LBAs_Written) — суммарный объём записанных данных в логических блоках, аналог data_units_written.
• ID 5 (Reallocated_Sector_Count) и ID 197 (Current_Pending_Sector) — количество секторов, уже переведённых в резерв, и секторов под подозрением. Рост этих чисел — не про износ NAND напрямую, но такой же ранний сигнал проблемы диска.

Автоматизировать проверку легко — например, забрать нужные значения в скрипт мониторинга:

smartctl -A /dev/sda | grep -E "Wear_Leveling|Media_Wearout|Reallocated"

Практический ориентир (именно ориентир, не гарантия): если percentage_used у NVMe уверенно перевалил за 80%, а media_errors или Reallocated_Sector_Count начали расти month-over-month, — самое время планировать замену диска заранее, в плановое окно, а не разгребать последствия отказа под нагрузкой.

Что реально влияет на скорость износа на практике

Несколько вещей, которые вы контролируете напрямую и которые ощутимо меняют, как быстро диск «съедает» свой ресурс:

• Оставленное свободное место. Чем меньше на диске свободного пространства, тем меньше у контроллера манёвра для wear leveling и garbage collection и тем выше write amplification. Правило «не забивать SSD под завязку» — не суеверие, а прямое следствие того, как устроен FTL.
• TRIM/discard. Команда TRIM сообщает контроллеру, какие блоки логически свободны и их можно стирать заранее, а не в момент новой записи. Без TRIM (например, на некоторых конфигурациях RAID-контроллеров, которые его не пробрасывают) диск вынужден стирать «вслепую» под нагрузкой, что увеличивает задержки и износ. Проверить, что TRIM работает на Linux: fstrim -v / для файловой системы или lsblk --discard для поддержки на уровне устройства.
• Размер записи и профиль нагрузки. Много мелких случайных записей (типично для активных баз данных, логов с частым fsync) изнашивают диск заметно быстрее, чем последовательная запись большими блоками того же суммарного объёма — из-за того же write amplification.
• Оверпровижининг. Часть серверных NVMe позволяет вручную увеличить резерв контроллера сверх заводского (например, через nvme-cli или утилиты производителя), уменьшив видимую пользователю ёмкость в обмен на больший запас блоков под ротацию — это осмысленный компромисс для дисков под тяжёлую запись, а не универсальная рекомендация всем подряд.
• Температура. Флеш-память чувствительна к перегреву — при устойчиво высокой температуре деградация ячеек ускоряется, поэтому у NVMe в SMART отдельно есть поле температуры и порог throttling, при котором контроллер сам снижает скорость, чтобы не жарить память.

Если для вашей задачи запись действительно интенсивная — стоит закладывать выбор диска под неё заранее, а не постфактум: разница между SATA SSD и NVMe касается не только скорости, но и типичного класса ресурса — подробнее в материале NVMe против SATA SSD на сервере.

Частые вопросы