У SSD большой емкости есть неприятная операционная деталь: перед честными тестами их надо довести до steady state. Для накопителей на 64 ТБ, 128 ТБ и 256 ТБ это уже не вечерняя лабораторная процедура, а отдельный этап в графике квалификации.
SanDisk предложила для этой задачи Sprandom, SanDisk Pseudo Random. Это метод random preconditioning для fio: он записывает устройство по рассчитанному псевдослучайному шаблону и быстрее приводит SSD к состоянию, похожему на steady state после длительной random-write нагрузки.
По материалам SanDisk, обычный preconditioning для SSD большой емкости может занимать 144+ часов, а Sprandom укладывается чуть больше чем в 6 часов. В отраслевых публикациях встречается и более жесткая оценка: больше 160 часов для 128 ТБ и до 250 часов для 256 ТБ при классической процедуре.
Главное здесь не в том, что SSD начинает работать быстрее. Sprandom сокращает путь к состоянию, в котором накопитель можно тестировать честно.
Новый SSD из коробки часто показывает не ту производительность, которую он будет держать после длительной эксплуатации. В начале теста у контроллера еще слишком удобные условия: logical-to-physical mapping только заполняется, garbage collection не вышел на рабочий режим, over-provisioned область еще не распределена так, как после долгой random-write нагрузки.
Поэтому перед performance-тестами SSD доводят до steady state. В этом состоянии внутренняя работа контроллера, NAND media management, garbage collection и wear leveling уже ближе к реальному production-поведению.
Для enterprise и datacenter SSD это принципиально. Там измеряют не красивый burst на свежем диске, а sustained IOPS, latency distribution, tail latency, mixed workloads, write amplification и стабильность под длительной записью. SanDisk отдельно связывает preconditioning с измерением sustained performance и с методологией SNIA Solid State Storage Performance Test Specification.
Классический random preconditioning обычно начинается с полной последовательной записи устройства. Затем идет длинная random-write фаза, пока диск не выйдет на устойчивый режим.
Для SSD на несколько терабайт это было терпимо. Для 128 ТБ и выше время начинает масштабироваться болезненно. Если лаборатория квалифицирует десятки накопителей, сравнивает firmware, прогоняет burn-in или готовит инфраструктуру под AI-кластер, preconditioning внезапно становится узким местом всего цикла.
И это не редкая лабораторная экзотика. Чем плотнее становятся NVMe-пулы, тем чаще storage-команды сталкиваются с ситуацией, где тест еще не начался, а календарь уже горит.
Sprandom заменяет долгий random-write прогон одним рассчитанным проходом. Метод использует информацию об over-provisioning и строит pattern записи так, чтобы заполнить L2P-таблицу, распределить OP по physical media и получить состояние, похожее на steady state для 100% random write workload.
В pull request к fio авторы описывают четыре цели: записать каждый LBA хотя бы один раз, добиться steady-state распределения OP, избежать физически последовательных L2P entries и при этом не разнести логически соседние адреса по физическому пространству слишком хаотично.
В fio это не просто новый random generator. В реализации есть модель validity distribution по регионам, оценка write amplification через over-provisioning, расчет валидности блока, который может выбрать garbage collector, и распределение invalid blocks по physical regions.
Идея выглядит так: не ждать, пока SSD сам накопит нужное внутреннее состояние после огромного числа random writes, а заранее построить запись, которая приближает диск к этому состоянию.
В текущей документации fio Sprandom включается параметром sprandom=1. Метод делит устройство на регионы и записывает физическую емкость один раз, выбирая offsets так, чтобы распределение invalid blocks в регионах напоминало steady state.
Ключевые параметры простые:
sprandom=1 spr_op=0.15 spr_num_regions=400
spr_op задает over-provisioning ratio, обычно по данным производителя SSD. spr_num_regions управляет числом регионов. Для больших устройств большее число регионов дает более точную модель, но влияет на память. fio также использует random_generator=lfsr; другой generator для Sprandom приведет к ошибке.
Pull request #1954 в axboe/fio был смержен 22 августа 2025 года. В презентации SNIA SDC 2025 SanDisk также показывает интеграцию в fio и пример jobfile с sprandom=1.
Sprandom не отменяет benchmark-дисциплину. Температура, power state, firmware version, queue depth, block size, write cache settings, secure erase или format перед тестами, NUMA affinity и PCIe topology остаются такими же важными.
Есть и более тонкий момент: Sprandom зависит от корректной оценки over-provisioning. Чем точнее известно соотношение user capacity и physical capacity, тем лучше модель. По заявлению SanDisk, метод применим к NVMe, SAS и SATA SSD, но качество конкретного теста все равно будет зависеть от данных о накопителе и от аккуратности fio jobfile.
Sprandom также не повышает IOPS сам по себе. Он сокращает время подготовки диска к состоянию, в котором IOPS и latency можно измерять без самообмана.
Sprandom хорошо показывает, что рост емкости SSD меняет не только сами накопители, но и процедуры вокруг них. Когда SSD были на 2-8 ТБ, preconditioning раздражал, но редко ломал процесс. На 128-256 ТБ это уже отдельный bottleneck.
SanDisk предложила не грубую ускоренную запись, а модель внутреннего steady-state состояния SSD. Интеграция в fio делает метод заметнее: теперь это может стать частью обычной практики performance engineering, а не особенностью одного vendor workflow.
Для дата-центров, AI-инфраструктуры и разработчиков СХД ценность Sprandom простая – быстрее получить честную картину поведения SSD. В инженерии хранения это часто важнее красивого пика на графике.
Добавить комментарий
Комментариев пока нет