Месяц назад на Хабре вышла статья о том, почему SSD со временем становится медленнее, и одна мысль оттуда засела у меня в голове и крутилась как назойливая песня: SMART может показывать полное здоровье и ноль ошибок, пока диск тормозит по вполне конкретным причинам. У меня системным диском стоит Team MP33 на 512 ГБ, у него уже почти 14 тысяч часов работы, и мне стало интересно, что из этого подтвердится на нем самом, а что так и останется красивой теорией.

Итог уже в заголовке: smartctl выдал PASSED, ноль ошибок и ноль минут перегрева, а меньше чем через минуту непрерывной записи тот же диск писал по 22 МБ/с. Дальше расскажу, что SMART на самом деле считает, как я мерила запись и температуру и почему сравнение «старый файл против свежего» так легко обманывает. Все цифры ниже сняты в один вечер на одном диске под Windows 11, замеры делал fio, а состояние диска я снимала smartctl до и после тестов.

Что на самом деле считает SMART

Начнем с того, что диск говорит о себе сам. У NVMe-дисков есть стандартный журнал SMART/Health, и smartctl показывает его целиком. Вот самое интересное из того, что он выдал перед тестами:

SMART overall-health self-assessment test result: PASSED
Critical Warning:                   0x00
Temperature:                        41 Celsius
Available Spare:                    100%
Percentage Used:                    14%       израсходованный ресурс, по оценке самого диска
Data Units Read:                    143,754,623 [73,6 TB]
Data Units Written:                 95,798,840 [49,0 TB]
Power On Hours:                     13,866
Unsafe Shutdowns:                   375
Media and Data Integrity Errors:    0         только ошибки, которые исправить не удалось
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0

Percentage Used по стандарту NVMe означает оценку производителя, какую долю расчетного ресурса диск уже израсходовал, и на моих 49 ТБ записи она составляет 14%. CrystalDiskInfo для NVMe, насколько я знаю, показывает здоровье как 100 минус это число, так что у меня он покажет «Хорошо» и 86%. Available Spare говорит, сколько осталось резервных блоков на замену умершим, а Media and Data Integrity Errors считает только те ошибки, которые контроллер так и не смог исправить. Сколько сил ушло на исправление всех остальных, стандартный журнал не записывает вообще. Диск, кстати, пережил 375 небезопасных отключений и по собственному же мнению (которому мы, конечно же, верим) не потерял ни байта.

Все поля журнала отвечают на два вопроса: сколько диску осталось жить и не начал ли он уже терять данные. Поля «сейчас я пишу в медленном режиме» или «этот файл я перечитывал трижды» там нет, и сколько на самом деле пишет флеш, из него тоже не узнать. Data Units Written считает то, что прислал компьютер, в единицах по 512 000 байт. За время моего теста записи счетчик вырос на 61 954 единицы, то есть на 31,7 ГБ, а fio записал 27,9 ГБ. Оставшиеся почти четыре гигабайта за эти же несколько минут дописала в фоне Windows, и это счетчик видит. А вот сколько раз контроллер перекладывал эти данные внутри себя, уже нет.

Запись: где кончился кэш

Запись я мерила fio с прямым доступом к диску, чтобы Windows не складывала данные в свой кэш в оперативке: один файл, блоки по мегабайту, восемь запросов в очереди и скорость в лог раз в секунду. Файл получился скромный, 26 ГиБ, он же 27,9 ГБ: диск занят на 84,5%, свободно около 74 ГБ, и забивать системный диск под завязку ради одного графика мне не хотелось.

Первую секунду диск писал больше 2 ГБ/с, следующие четыре секунды проседал до 45–60 МБ/с, потом около тринадцати секунд держал 600–900 МБ/с и под конец выдал короткий рывок до 2,4 ГБ/с. К 23-й секунде на диск ушло примерно 20 ГБ, и на этом праздник закончился. С 25-й секунды и до конца теста медиана скорости составила 73 МБ/с, а с 51-й по 59-ю секунду диск стабильно писал 15–22 МБ/с, то есть медленнее обычного жесткого диска, который при последовательной записи выдает больше 100 МБ/с. В среднем 27,9 ГБ записались за 96 секунд, около 290 МБ/с, и эта цифра хорошо показывает, как среднее прячет поведение диска: большую часть времени он работал в разы медленнее.

Раз в 12–23 секунды на графике появляются одиночные всплески до 480–790 МБ/с. Похоже, контроллер в фоне освобождает немного быстрого кэша, и новая порция данных тут же его занимает, но это моя интерпретация, такие вещи производитель не документирует. Пики выше паспортных 1400 МБ/с, которые обещаны для версии на 512 ГБ, меня смутили. Скорее всего, это следствие усреднения по секундам и буферов по дороге, так что всерьез опираться на них я бы не стала.

Механика тут известная. В ячейке TLC хранятся три бита, и писать туда медленно, потому что контроллеру нужно аккуратно загнать заряд в один из восьми узких уровней. Поэтому часть свободного места диск использует в режиме SLC, по одному биту на ячейку, сначала пишет все туда и потом перекладывает в нормальный режим. Под такой кэш уходит свободное место, и чем плотнее забит диск, тем меньше ему остается. AnandTech в своей методике тестирования нарочно гонял часть тестов на диске, заполненном на 80%, именно потому, что при такой заполненности SLC-кэш заметно сжимается. Мой диск с его 84,5% как раз из этой категории.

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

Some like it hot

Первое, что приходит в голову при таком провале скорости, это перегрев: контроллер упирается в порог и сбрасывает частоты, чтобы не сгореть. Пока шла запись, скрипт раз в пять секунд спрашивал у Windows температуру диска, и максимум за весь тест составил 47 °C при предупредительном пороге 70 °C и критическом 80 °C. В журнале SMART для этого есть два счетчика, Warning и Critical Comp. Temperature Time, они показывают, сколько минут за всю жизнь диск провел выше этих порогов. До теста в обоих стояли нули, после теста тоже, так что троттлинг я с чистой совестью вычеркиваю. К провалу до 22 МБ/с он отношения не имеет.

Но в том же журнале нашлась странная строчка. Кроме основной температуры диск отдает показание Temperature Sensor 1, и оно заметно выше: до теста 60 °C против 41, после теста 66 °C против 45. Пороги перегрева, насколько я понимаю спецификацию NVMe, сравниваются с основной температурой, которую производитель считает по своей формуле, а что именно внутри греется до 66 градусов, хз, расписания датчиков я для этой модели не нашла. До порога там все равно оставалось прилично, но если смотреть только на основную цифру, об этих двадцати градусах разницы просто не узнаешь.

Если на клетке слона написано «буйвол»

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

Самым старым подходящим файлом на диске оказалось видео на 2,8 ГБ, снятое на дефолтное приложение винды 19 апреля (не спрашивайте, о чем видео, мои попытки стать блогером должны уйти со мной в могилу), то есть пролежавшее 163 дня. fio читал его блоками по мегабайту, по одному запросу за раз, сначала дважды оригинал, потом свежую копию. После этого я собиралась дать диску постоять час и перечитать оба файла, но терпения хватило на 18 минут (каюсь). Вот что получилось:

Смотрите, как красиво выглядит третья строчка. Свежая копия читается на треть быстрее старого файла, и если на этом остановиться, гипотеза про стареющие данные подтверждена и можно идти писать статью. Через 18 минут простоя та же копия замедлилась до 1286 МБ/с, практически до скорости старого файла. Треть скорости давал SLC-кэш из прошлого раздела: свежезаписанные данные лежали в ячейках с одним битом, и читать их оттуда быстрее. Медианная задержка одного чтения у свежей копии была 544 мкс, а у всех остальных замеров около 745 мкс, и как только контроллер переложил копию в обычные ячейки, разница исчезла.

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

По средней скорости мой пятимесячный файл от отлежавшейся копии не отличается, 1261 против 1286 МБ/с влезает в погрешность. Зато в последнем столбце есть слабый намек: у старого файла чтений дольше миллисекунды в два–четыре раза больше, чем у копии, а 99-й процентиль задержки 1,2–1,9 мс против 0,95 мс. Это может быть самым началом эффекта утечки заряда, когда редкие страницы уже приходится перечитывать. А может быть и прозаичнее: видео писалось с камеры кусками вперемешку с другими данными и лежит на флеше вразброс, а копия записалась одним куском. По одному файлу эти версии не различить, и это второй мой тупик: для честного ответа нужны файлы старше года и желательно не один, а самый старый файл на моем диске оказался моложе полугода.

Что находили другие

Раз уж мой диск на вопрос про старые файлы ответить не смог, я поискала, кто проверял это раньше. История началась в 2014 году с Samsung 840 EVO: в ветке на Overclock.net владельцы заметили, что файлы возрастом в несколько месяцев иногда читаются медленнее 50 МБ/с. Год этого никто не видел ровно по той причине, о которой я писала выше: бенчмарки читают только свежие файлы. Автор ветки написал для проверки отдельную программу, SSD Read Speed Tester, которая читает уже лежащие на диске файлы и рисует скорость против их возраста. Samsung в итоге выпустила прошивку, которая периодически переписывает залежавшиеся данные.

Потом той же программой гоняли 850 EVO, и на форуме AnandTech картина получилась пестрая: у одного участника замедление появлялось на файлах старше 21–24 недель, у другого на двенадцатинедельных файлах падения не было вовсе. Свежие случаи тоже есть. В 2023 году владелец PCIe 4.0 NVMe жаловался на HardForum, что тормозят только старые данные, а свежие файлы в порядке, и в итоге сдал диск по гарантии. В 2025 году там же обсуждали QLC-диск, у которого старые файлы читались на 150–160 МБ/с, а свежезаписанные на 550–560, и автор сам заподозрил, что pSLC-кэш маскирует чтение в бенчмарках. Это ровно та ловушка, в которую меня чуть не затянула свежая копия.

Есть и более строгие цифры. В статье RARO на arXiv авторы меряли, во что обходятся повторные чтения на QLC: один повтор сокращал скорость последовательного чтения вдвое, десять повторов оставляли от нее меньше десятой части. Сам эффект, судя по всему, реальный, но его сила сильно зависит от типа памяти, возраста файла и того, обновляет ли контроллер данные сам. На моем диске с его паспортным TLC и пятимесячным файлом он по средней скорости еще не проявился, и утверждать про него что-то своими цифрами я не буду.

Коробка одна, начинка разная

Когда я полезла искать обзоры своего диска, чтобы сравнить цифры, выяснилось, что сравнивать особо не с чем. По данным Tom's Hardware, MP33 вышел с контроллером Phison E13T, а в их образце уже стоял Silicon Motion SM2263XT с памятью Micron 96L TLC. Оба контроллера безбуферные, а SM2263XT держит часть таблицы трансляции адресов в оперативке компьютера. В комментариях к тому же обзору читатель пишет, что купил MP33 из-за контроллера Silicon Motion, а получил экземпляр с Realtek RTS5763DL.

У моего экземпляра smartctl показывает PCI Vendor ID 0x1ed0 и прошивку APF1M3R0. Насколько я знаю, у Phison идентификатор 0x1987, у Silicon Motion 0x126f, у Realtek 0x10ec, так что кто у меня внутри, хз, и разбирать системный диск ради ответа я пока не готова. Для бюджетных дисков это обычная история, но у нее есть неприятное следствие: обзор модели с красивым графиком кэша может описывать совсем другое железо, чем то, что лежит у вас в коробке. Мои цифры тоже про мой конкретный экземпляр и больше ни про кого.

Пациент скорее жив

За весь вечер тестов SMART не поменял ни одной своей оценки: те же 14% износа, ноль ошибок, ноль минут перегрева и PASSED в самой первой строчке, хотя за это время диск успел писать и на 2 ГБ/с, и на 22 МБ/с. И в этом он честен: его спрашивают про остаток ресурса и потерю данных, и про это он отвечает точно. Про скорость его просто никто не спрашивал, и если диск тормозит, а в состоянии написано «Хорошо», смотреть надо в другую сторону, и в моем случае эта сторона называется «свободное место».

Диск, кстати, до сих пор занят на 84,5%, и чтобы по уму показать, как длина быстрого участка зависит от заполненности, мне сначала придется решить, какие сто гигабайт на системном диске мне не так уж нужны. Пока я выбираю, с чем мне проще расстаться, SMART по-прежнему уверен, что у него все хорошо.