Технологии сжатия данных DuraWrite и SmartZIP: специальная обработка повторяющихся последовательностей данных контроллерами SSD
Тестирование твердотельного накопителя Seagate IronWolf 110 емкостью 240 ГБ
В прошлом году мы тестировали твердотельный накопитель Seagate IronWolf 110 емкостью 240 ГБ и, в частности, упомянули, что используемый в нем «фирменный» контроллер тесно связан с разработками некогда знаменитой SandForce. Точнее, популярной продукция этой фирмы начала становиться еще во времена семейства «1000» с поддержкой SATA300, а на контроллерах SandForce линейки «2000» SSD выпускали чуть ли не все производители того времени. Но были у первых разработок и свои недостатки, которые планировалось исправить (а сильные стороны — укрепить) в следующем условно «3000»-м семействе. Разрабатывали его, фактически, с чистого листа, изначально предполагалась модульная архитектура, позволяющая, например, гибко менять внешний интерфейс (SATA, PCIe x2 или PCIe x4), но... Первые подробности были раскрыты еще в 2013 году, потом стало известно, что контроллеры будут доступны всем желающим к концу 2014-го, затем их выход был перенесен на 2015-й… В общем, за это время на рынке многое изменилось, он начал консолидироваться вокруг непосредственных производителей флэш-памяти и/или контроллеров. В таких условиях в Seagate (к тому моменту поглотившей компанию LSI, которая, в свою очередь, чуть раньше «переварила» SandForce) было решено не пытаться конкурировать на открытом рынке, а использовать собственные разработки в собственных же продуктах — причем предназначенных для корпоративного рынка, т. е. семействе SSD Nytro. (В общем-то, и эта марка «досталась» Seagate вместе с LSI.) А протестированный нами IronWolf 110, по сути, является ближайшим родственником Nytro 1351, но для более широкого круга покупателей.
Понятно, что Seagate ST22G4000AB (он же SF-4500) существенно отличается от SandForce SF-1222 десятилетней давности. Но неизменным остается одно — технология DuraWrite, сущность которой заключается в сжатии повторяющихся последовательностей данных (в первую очередь нулей) с добавлением «освобожденных» блоков к резервным. Стоит отметить, что под конец активного жизненного цикла контроллеров SF-2281 (последних массовых) в среде энтузиастов было принято настороженно относиться к данной технологии: ее работа радикальным образом влияла на производительность низкоуровневых тестовых утилит, в особенности при использовании низкоскоростной памяти. Поскольку физический объем записи при сжатии нулей сильно снижался, можно было наблюдать выдающиеся показатели в результатах тестирования, независимо от того, сколько «выдерживал» сам флэш. Разумеется, этим активно пользовались производители SSD, декларируя как раз эти самые «выдающиеся показатели» :) Соотношение же их с реальностью могло быть весьма причудливым — и сильно зависело от этой самой «реальности».
Для примера приводим диаграмму из одного старого обзора. Все, что менялось в тесте — набор данных в CrystalDiskMark 3.0.1: либо нули, либо несжимаемые данные. А приведены соотношения производительности в процентах по тестам чтения и записи (и последовательные операции, и «мелкоблок») в таких условиях. Первый участник — накопитель на контроллере SiliconMotion SM2246EN, специальной обработкой данных не занимавшемся. Оно и видно: скорости совпадают с точностью до погрешности. Второй и третий — SSD на SandForce SF-2281. И здесь скорость «записи» нулей более чем в два раза превышает возможности памяти. А асинхронный флэш в Kingmax SMG32 Titan еще и читается «по-честному» медленно, так что при работе с нулями даже скорость чтения у него радикально повышается. Похоже вел себя и накопитель на базе Phison S8 (последний участник), где как такового сжатия данных нет, но специальная обработка нулевых блоков есть. Причем заметим: все это «безобразие» творилось во времена тотального господства MLC-памяти. Будь тогда у производителей в распоряжении TLC или тем более QLC (где со скоростью записи дела всегда обстояли еще хуже) — игра со скоростными показателями вообще вышла бы на небывалые высоты. Так что многие компании, не использующие контроллеры SandForce, активно продвигали в рекламе лозунги типа «TrueSpeed» — мол, у нас-то со скоростью все по-честному, а не как у некоторых.
Но на самом деле подобные результаты тестовых утилит — лишь побочное следствие работы DuraWrite. Затевалось-то все совсем с другой целью.
Зачем сжимать нули и откуда они берутся?
Мультимедийные технологии начали развиваться около 30 лет назад и сразу же породили проблему хранения и обработки больших объемов информации. Результатом этого стало развитие алгоритмов сжатия данных с потерями — без чего, например, какое-нибудь цифровое 4К-видео в качестве массового явления было бы просто невозможно. Конечно, в процессе создания контента для повышения качества иногда приходится работать и с несжатыми данными (или lossless-алгоритмами), но конечный продукт всегда «упаковывается» радикальным образом. Иначе — никак, поскольку, например, Canon C200 при съемке в формате 4K Cinema RAW Light при 50 кадрах в секунду «пожирает» пространство со скоростью 7,5 ГБ в минуту. При экспорте RAW-исходника в ProRes 4444 объем практически удваивается. Понятно, что даже при нынешнем уровне развития каналов связи и накопителей «конечное» видео в таких форматах окажется недоступно подавляющему большинству потребителей. Вот никто его в таких форматах и не сохраняет (и не передает). А в тех форматах, которые используются, отброшены даже малозначимые детали, не говоря уже о таких простейших методах повышения энтропии, как сжатие повторяющихся последовательностей.
Поэтому вынесенный в заголовок вопрос применительно к мультимедийным данным смысла не имеет: если там «нули» и были изначально, то их уже сжали. А если не было, то близкие к нулевым данные превратили в нули — и тоже сжали. При этом именно «разнообразная мультимедия» (в первую очередь — видео, но картинки и звук «компактны» лишь на его фоне, а не в сравнении с текстом) сегодня является определяющей в плане требований индивидуальных пользователей к емкости устройств хранения информации. Но она же в 99% случаев является и «холодными» данными, т. е. теми, к которым не нужен быстрый доступ. В итоге мультимедийные файлы до сих пор нередко «лежат» на винчестерах в NAS, а то и вовсе на оптических дисках. Твердотельные же накопители использовать для хранения такой информации все еще расточительно: удельная стоимость каждого гигабайта у них намного выше, чем у двух упомянутых типов накопителей. А вот то, что попадает на SSD, обычно организовано совсем по-другому.
В частности, нулевые байты активно используются для выравнивания структур данных на определенные границы. Либо для инициализации по умолчанию статических переменных (или массивов) — заполняться реальными данными они будут уже в процессе работы после загрузки в память. В общем и целом, для исполняемых файлов или динамических библиотек количество нулей (причем не одиночных, а в виде последовательностей — и иногда достаточно длинных) может достигать половины размера файла. Но и файлы данных, где с местом принято обходиться «более бережно», не всегда от них отстают — к примеру, даже в файлах сжатых форматов Microsoft Office нулей порядком. Файлы баз данных при добавлении записей также нередко инициализируются нулями — не говоря уже о том, что что таковых много и между записями для их выравнивания.
На самом деле, при работе системы может сложиться ситуация, когда и «мультимедийный» файл изначально будет состоять только из нулевых байтов. Так работают клиенты Р2Р-сетей, если указать им резервировать место под большой файл сразу — чтобы не фрагментировался при скачке. Точнее, конечно, нулями по умолчанию заполняют отведенное пространство системные функции (способ отказаться от этого есть, но не во всех случаях работающий). А вот потом уже в процессе скачки файл «наполняется» реальными данными.
В принципе, подобных ситуаций бывает много, на чем основаны механизмы разреженных файлов и/или встроенных функций сжатия файлов средствами NTFS. Ну и обычные архиваторы, конечно, это используют. Во всех случаях подход применяется для экономии места на диске, что не всегда оправдано при оперативной работе. Например, можно создать разреженный файл на 10 ГБ, даже имея на диске всего 1 ГБ свободного места — «дырки» не считаются. Только вот если мы потом начнем заполнять их данными, фокус может и не пройти — место кончится раньше, чем все они будут записаны. Такие же проблемы бывают и со сжатыми разделами, если попробовать записывать на них файлы с несжимаемыми данными: исчерпание свободного места может произойти куда ранее, чем прогнозировалось.
Сжатие и «псевдосжатие» нулей
DuraWrite работает немного по-другому. Нужно ли записывать все нули на диск? Нет — тем более, что они могут быть позднее перезаписаны другими данными. А в случае твердотельного накопителя нам совсем не нужны «лишние» операции записи. Можно ли считать место, занимаемое нулями, свободным? Нет — по той же причине. Можно ли добавить его к резервным блокам? А вот это — можно и нужно! При этом как там хранится информация на диске — знает только контроллер. А возникновения фрагментации можно не опасаться: все равно соответствие «физических» блоков хранения информации и «логических» адресов устанавливает он же.
Получается крайне удобная ситуация. На SSD «записано» 10 ГБ нулей — но на самом деле ни одного. Точнее, какое-то количество информации запишется, чтобы закодировать все эти последовательности, но далеко не 10 ГБ. А то место, которое занимали бы нулевые блоки, можно свободно использовать для выравнивания нагрузки и другой «внутренней работы». Если же в последующем все «дырки» будут заполнены ненулевыми данными — ничего страшного: только тогда и произойдет физическая запись, а резервных ячеек станет столько, сколько было бы без DuraWrite, но не меньше. То есть как минимум ничего не теряем, а можем и что-то приобрести. В том числе выигрываем в производительности — вплоть до «упирания» в скорость интерфейса даже на медленном флэше. Что, в общем-то, и «погубило» эту технологию на массовом рынке — по крайней мере, в какой-то степени (причины описаны выше).
Примечательно, что негатив по отношению к SandForce не распространился на контроллеры Phison, хотя они тоже зависят от типа используемых данных. Просто SmartZIP (так эта технология именуется у Phison начиная с S11, хотя частичная ее реализация появилась в более ранних контроллерах) использует несколько более простой алгоритм, нежели DuraWrite: специальным образом обрабатываются только блоки, состоящие целиком из нулей. В некоторых случаях результат будет аналогичным DuraWrite: при резервировании места под файл, например, в SSD на части контроллеров Phison (в частности, том же S11) модифицироваться будет только таблица трансляции, но не основной массив ячеек. В некоторых случаях будет иначе: если в блоке найдется хоть один ненулевой байт, DuraWrite из этого что-то выжать сможет (особенно когда таких блоков в файле много), а вот SmartZIP с ним будет работать как с заполненным случайными данными целиком. Однако когда речь идет о действительно «гигабайтах нулей», то «подходящих» обоим технологиям блоков найдется много. Кроме того, при работе с нулевыми блоками в случае контроллеров Phison радикально увеличивается и скорость чтения: при использовании DuraWrite нужно «честно» читать и «разжимать» данные, а эти, получив запрос к особому блоку (для чего даже не нужно к нему обращаться физически — информация может храниться прямо в таблице трансляции адресов), сразу же выдают на интерфейс последовательность нулевых байтов нужной длины. Вот эта часть алгоритмов «псевдосжатия» реализована, кстати, во всех контроллерах Phison — даже тех, которые запись нулевых блоков оптимизировать не обучены. Но, повторимся, данный подход менее гибок, так что SandForce и их наследники в реальных условиях могут «нарезервировать» себе гораздо больше флэша. Да и «обманывать» тестовые утилиты им будет удаваться чаще, хотя не для того все затевалось.
Зато работу этого побочного эффекта можно оценить на практике. Чем мы сейчас и займемся.
Методика тестирования и испытуемые
По понятным причинам «гонять» тесты высокого уровня не имеет смысла — они «заточены» под готовые трассы. Нулевых байтов в последних может быть много, однако изменить их количество (и посмотреть, что выйдет) не получится. А вот с низкоуровневыми утилитами все проще. В частности, используемая нами для тестов программа CrystalDiskMark 6.0.0 для тестирования может «готовить» блоки со случайными данными (что мы обычно и используем), а может заполнять их нулевыми байтами (чем мы воспользуемся сегодня). Anvil’s Storage Utilities 1.1.0 идет еще дальше: тут уровней энтропии несколько. По умолчанию выбран режим 100% (т. е. несжимаемые данные), который обычно и используется. Однако программа, подобно CDM, может работать и с «чистыми» нулями, а также с несколькими промежуточными значениями регулярности данных: 8%, 25%, 46% и 67% «сжимаемости». 8% считается (самой программой и не только) типичным значением для файлов баз данных, 46% — для приложений, поэтому мы решили провести тесты и в таких условиях.
Кого будем тестировать? Главный герой — Seagate IronWolf 110 емкостью 240 ГБ, к которому мы снова добавим «историческую» модель на SandForce SF-2281 и eMLC-памяти Intel той же емкости, а именно PNY Prevail Elite. Для иллюстрации разницы подходов SandForce и Phison нам пригодится Patriot Burst на те же 240 ГБ — в нем используется Phison S11 и 96-слойная память TLC NAND Toshiba BiCS4 (для чистоты эксперимента лучше бы подошла 64-слойная BiCS3, как в IronWolf 110, но найти сейчас такую конфигурацию уже сложно). А эталонной точкой отсчета послужит SanDisk Ultra 3D 250 ГБ: контроллер Marvell 88SS1074 хитрым трюкам со сжатием не обучен, а память — та же BiCS3. Впрочем, упирать на идентичность памяти в сегодняшнем тестировании мы не будем (даже когда оно есть), поскольку SanDisk и Patriot (как и положено современным накопителям) поддерживают SLC-кэш, а вот Seagate и PNY обходятся без него. Так что в первую очередь нас будет интересовать зависимость каждого накопителя от данных и сравнение тенденций, а не абсолютных результатов.
CrystalDiskMark 6.0.0
«Эталонному» SanDisk Ultra 3D все равно, что читать — как и должно быть. SandForce и его наследникам — не все равно: порядка 40 МБ/с на нулях мы получаем дополнительно. Почему не больше? Потому, что данные все равно нужно читать, обрабатывать и «выдавать» на интерфейс. Но, в любом случае, хуже не становится. Особенно если говорить про «старые» накопители — в те годы скорость чтения была сама по себе более низкой, так что и прирост от подобных ухищрений в относительном исчислении более весом. Patriot Burst теоретически тоже должен демонстрировать увеличение производительности, а практически «потолком» тут можно считать собственные возможности контроллера: вот столько и не более он может выдавать на интерфейс в однопоточном режиме.
Причем в те годы это сказывалось даже в многопоточном режиме — который сегодня в накопителях среднего класса в любом случае «упирается» в способности SATA600. А вот бюджетный Phison S11 из-за всего двух каналов флэш-памяти не умеет даже быстро читать из нее данные — но при обработке блоков из нулей это и не требуется, так что в таком режиме «гадкий утенок» начинает выглядеть как нормальный лебедь :)
Скорость «честной» записи у основных испытуемых невысока, что объясняется в одном случае использованием старой и достаточно медленной памяти, пусть и MLC, а во втором — отсутствием поддержки SLC-кэширования: плохой случай для TLC. Но стоит перейти к хорошо сжимаемым данным — так сразу выходим как минимум на уровень современных «быстрых» устройств. Или, даже, лучше. Но! На все можно смотреть с разных сторон: говоря либо об ускорении при работе со сжимаемыми данными, либо о... «тормозах» на несжимаемых. Именно такая претензия в свое время и подпортила репутацию SandForce как только конкуренты освоили более высокие скорости вне зависимости от «сжимаемости» данных. Кто знает — подтяни компания производительность в «3000»-м семействе и сделай его доступным всем желающим, возможно, ей бы удалось реабилитироваться. Но события развивались несколько по-иному.
Что характерно, для Phison S11 даже при использовании оптимальной стратегии кэширования (т. е. «переключением» в режим прямой записи после заполнения SLC-кэша) переход к нулям тоже полезен. Ничего удивительного — пара каналов и при использовании BiCS4 обеспечивает лишь немногим более 100 МБ/с если данные нужно записывать в TLC-массив, так что отказ от самой по себе записи в пользу лишь маркировки «нулевых» блоков радикально повышает скорость.
А вот многопоточная запись к типу данных восприимчива лишь в случае «старого» и «нового» SandForce. Причем есть серьезные подозрения, что второму SLC-кэширование дало бы больше. Либо просто большее количество памяти — напомним, что в линейке IronWolf 110 модель на 240 ГБ стоит особняком и по заявленной скорости записи: лишь 230 МБ/с против 485 МБ/с 480 ГБ или и вовсе 535 МБ/с остальных модификаций. Так что остается лишь отметить, что, к чести Seagate, указаны именно показатели для несжимаемых данных — во времена господства SandForce, как уже сказано, производители «обожали» декларировать скорость записи нулей.
Разница в подходах — в полный рост. DuraWrite латентность доступа к данным не снижает, так что результат от данных не зависит. SmartZIP этого тоже не делает — но и доступ на деле не нужен: достаточно определить, что речь идет о «нулевом» блоке и эти самые нули и выдать на интерфейс. Всё! Виртуальная производительность — на уровне Optane SSD, а вовсе не банального NAND-флэш.
На «длинных» очередях уже можно что-то соптимизировать, так что обе технологии производительность повышают. Особенно радикально — в случае старого SandForce, благо «по-честному» он с такой нагрузкой справлялся плохо. Новый же, наоборот, куда скромнее в плане ускорения, поскольку и так работает более-менее нормально. Но Phison S11 и на несжимаемых данных был быстрее, а на нулях вообще вырывается в лидеры.
И в таком «предельном» случае он тоже бодро наращивает производительность и выходит в лидеры. Оба SF — скромнее в обоих смыслах. А, главное, не так уж в этом случае что-то улучшать и требуется — SanDisk Ultra 3D на уже достаточно старом контроллере от типа данных не зависит и все равно работает быстро. В полтора раза быстрее, чем IronWolf 110 на той же памяти.
Абсолютные результаты сравнивать нужно очень осторожно — поскольку один накопитель использует MLC-память, а двое оперируют SLC-кэшированием, так что полной корректности добиться невозможно. Важнее динамика. А с ней все просто — способность «не писать нули» производительность может увеличить почти в полтора раза, когда эти «нули» по интерфейсу и идут. Но может и не увеличить — пример чего Seagate: что-то писать все равно нужно, так что относительно медленная память (TLC без кэширования) ускориться не даст.
На «длинной» очереди эффект еще более значимый. Причем такую работу можно и распараллелить внутри — так что и медленная память не помеха. Причем, что характерно, особого прогресса в этой области с давних времен нет — а вот «записываемые-незаписываемые» нули, как и встарь, дают огромнейший эффект.
AHCI — это одна очередь на 32 команды, в рамках чего можно оптимизировать запросы, так что разницы между одним потоком на 512 команд и «восемь-на-восемь» практически нет. За исключением S11 — который просто «захлебывается» данными, если их нужно честно записывать. А с нулями — расправляется шутя и очень быстро.
В общем, SandForce умер — но дело его живет. И в контроллерах Seagate (прямого наследника), и продукты Phison можно отлично «подстегнуть» выбором нулей в качестве тестовых данных. Как уже было сказано в начале — затевалось все не для этого. Просто побочный эффект. Но он есть.
С чем нужно поработать подробнее — все-таки в этой утилите доступны лишь две крайности. А Anvil’s Storage Utilities умеет работать и с промежуточными состояниями. Вот и интересно посмотреть — как это сказывается на практике.
Anvil’s Storage Utilities 1.1.0
В исследовательских целях на графики придется смотреть в масштабе — «приблизив» его верхнюю часть. Зависимость от данных в целом невысокая. У новых контроллеров Seagate — практически линейная по мере увеличения регулярности данных. У SF-2281 и Phison S11 речь, скорее, идет о двух состояниях. Первый действительно «тормозит» на случайных данных — но выходит на нормальный режим как-то только они становятся регулярными. А второй «умеет» работать только с полностью нулевыми блоками — зато очень быстро.
Скорость записи меняется в куда более широких пределах. Тройка накопителей на случайных данных работает одинаково, затем двое начинают ускоряться по мере увеличения количества нулевых данных. S11 вообще медленнее прочих — но когда нулей «много», то проскакивают уже и заполненные ими целиком блоки, так что производительность повышается до уровня SanDisk Ultra 3D. А на чистых нулях он и вовсе догоняет Seagate с PNY, благо для всех троих это практически одинаковый (в данной программе) и идеальный случай.
В принципе, ко всем графикам достаточно одного комментария — что-то интересное «выжать» из случайной записи без очереди DuraWrite не может, хотя по мере увеличения размеров блока немного повысить производительность и удается. А SmartZIP — именно технология работы с нулевыми блоками. «Промежуточные» варианты тут не имеют значения — они идентичны полностью случайным данным.
При работе с короткими очередями все также, как и вовсе без очереди. Причем и 16 команд все еще короткая очередь, хотя в персональном компьютере таких все еще вовсе никогда не встречается, да и в сервере считается нежелательным (как в магазине — если очереди есть, пришла пора разобраться с кем следует и наказать кого попало).
При записи же данных способность уменьшить количество этой самой записи важна всегда. Для DuraWrite это связано со сжатием — SmartZIP же особым образом обрабатывает «чистые нули» и только. В чем мы в очередной раз убеждаемся.
Если появляются очереди запросов, можно заняться и их оптимизацией, что само по себе дает неплохой эффект. Но с просто «отменяющей» запись работой технологии SmartZIP не сравнится ничто, конечно.
Пытаться свести все шаблоны к одному числу — занятие достаточно бестолковое. Но в данной программе оно есть — и в этом случае полезно, поскольку сразу видно, что если кто и «оптимизирован под нули», то это не старый (или обновленный) SandForce, а новый бюджетный Phison :)
Да и на операциях записи картина радикально не меняется. Тут уже, конечно, виден прирост от сжимаемости данных в случае использования DuraWrite — но и хорошо заметно, что это не только лишь чистые нули. В отличие от SmartZIP, которая эффективно работает именно с такими данными.
Конечный же результат является суммой этих двух, так что эффект только усиливается. В общем, если у вас много нулей — покупайте Phison. Хотя ругать за зависимость от характера данных принято было SandForce, но у него таковая выражена слабее — да и реализована немного логичнее.
Итого
Как видим, «специальная обработка» некоторых последовательностей данных после фактического ухода с рынка SandForce никуда не делась. И наследники SandForce от нее не отказались, и разработчики из Phison знамя подхватили. Зачем она нужна, было объяснено в начале статьи, так что повторимся: влияние на производительность в данном случае не главное, а лишь побочный эффект. Но эффект, конечно, иногда полезный — как и само по себе сокращение объемов записи.
Почему такой подход не стал более популярным за прошедшие годы? Как нам кажется, тут сказались два момента. Во-первых, несколько подмоченная репутация технологии DuraWrite — которую производители использовали в корыстных целях, завышая заявленные скоростные характеристики своих устройств. Во-вторых, чем дальше, тем сильнее сокращается актуальность подобных технологий. Одно дело — первые этапы, когда SSD в быту использовались исключительно для хранения операционной системы и программ: они неплохо сжимаются (выбранный в Anvil’s Storage Utilities коэффициент подтверждается и другими методами), так что эффективность DuraWrite высока. И совсем иное, если накопитель используется для хранения мультимедийных данных: они все равно не сжимаются. Когда-то флэш-память была слишком дорогой для такого использования, сейчас же львиную долю объема накопителя в каком-нибудь ноутбуке начинают занимать сериалы, фотографии, а у геймеров — сжатые текстуры, видеоролики и прочий подобный игровой контент. Словом, возни много, а выхлоп низкий. Но в ряде случаев полезный эффект можно получить и сегодня. Главное — заранее понимать, где и какой.
Полный текст статьи читайте на iXBT
