SSD без кэша не бывает

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

Случайно читать относительно быстро (50–60 мегабайт в секунду у лучших представителей SSD) можно прямо из массива с поправкой на крутость контроллера (здесь мы не останавливаемся, но тема контроллеров накопителей требует отдельного изучения — по сути, это сегодня уже многоядерные специализированные процессоры в составе «дисков», особенно твердотельных, и от их производительности и возможностей прямо зависят скорости работы накопителя) и канальность. Увеличить это можно только либо развивая твердотельные технологии, в т.ч. по части контроллеров, в сторону типа 3DXpoint, где можно читать случайно со скоростями до 300 (!) мегабайт в секунду, либо… предварительно кешируя прочитанное в более быструю память, т.е. в системную оперативную или собственный DRAM-буфер такого накопителя, которые, опять же, большими бывают нечасто и объемы DRAM-буферов обычно растут с рабочими объемами и… ценами же. Происходит так потому, что DRAM в SSD (да и в обычных HDD немного иначе, но тоже) используется в основном опять же для служебных данных типа таблиц соответствия (адресации) и т.п. Мы же помним, что логическому адресу данных, который «понимает» ОС, контроллером присвоится физический адрес внутри носителя, где движение данных происходит постоянно, но для внешнего мира адреса не меняются благодаря работе контроллера, как посредника между внутренним массивом и внешними контрагентами, которые вообще никак не подозревают, что там происходит внутри SSD в ходе TRIM и прочих процессов. Поэтому, кстати, при выходе контроллера из строя восстановить с SSD, состоящего из более чем одного чипа памяти, данные практически невозможно т.к. только контроллер «знает», опираясь на указанную таблицу, что и куда он распределял по твердотельному массиву. Т.е. рост объема DRAM-буфера — прямое следствие роста рабочего объема накопителя при заданной производительности контроллера. Нет, частично там что-то и из данных может задержаться, но это не точно. Типично сегодня можно встретить гигабайт DRAM-буфера на терабайт твердотельного накопителя. Как конкретно он используется и распределяется прошивкой — опять же широкой общественности неизвестно. Можно пытаться восстановить логику по результатам целевого тестирования, но смысл в этом будет только исследовательский, т.к. управлять ей не предлагается.

Со случайной записью картина аналогичная — быстро и случайно записать в массив не получится в общем случае. Поэтому запись тоже кэшируется — данные попадают сначала в самую быструю память, т.е. в кэш-буфер, и потом фоново переносятся в основной массив. Если DRAM-буфер задействован и заканчивается или его вообще не предусмотрели конструкцией, то в твердотельных дисках отводится часть основного массива, который, работая в быстром однобитном режиме, принимает входящий трафик сначала на себя, а потом, например, во время простоя или слабой нагрузки, фоново внутри накопителя без участия пользователя переписывает все свое содержимое в основной массив, усиливая показатели записи. Сегодня такое внутреннее кэширование осуществляется как фиксированными областями, работающими в быстром SLC-режиме, так и динамическими — вплоть до 40+ гигабайт у Samsung 860 QVO на терабайт тормозной QLC и 80 (!) гигабайт — на 2 ТБ модель. Обычные люди называют это кэшированием записи. Маркетологи Samsung преподносят это как специальную технологию TurboWrite! Видимо где-то на повороте потерялись слова мега, х1000 и прочие маркетинговые eye-стопперы. Ну, либо они оставлены на будущее.

Благодаря такому кэшированию, если базовый массив что в SDD, что тем более в HDD, относительно тормозной, то в случае объемной записи пользователь может благодаря местами огромной (до 80 гигабайт) быстрой «прокладке» вообще не ощутить медленности основной памяти накопителя. Вы часто пишите ходом более 40 гигабайт? Я — нет. И вы, уверен, в основном тоже. Поэтому все текущие операции будут происходить в быстрой памяти кэш-прокладки и лишь потом фоново переноситься на медленный массив для хранения.

Вы только что прочитали заготовку рекламной компании OLC SSD. Ой, я это вслух?

Важная деталь — если чтение записанного будет запрошено у накопителя системой ДО момента переноса данных из кэш-посредника в основную память, то такое чтение произойдет из кэша с соответствующей высокой скоростью. Если кэш будет в DRAM, что маловероятно, но, тем не менее, то обратное чтение будет осуществлено фактически со скоростью близкой к оперативной памяти, но в массе для SSD это кэш, где из основного массива, как упоминалось, выделяется часть для работы в быстрых режимах SLC. Все эти нюансы не предлагается настраивать пользователю. А зря.

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

Здесь появляется дилемма. С одной стороны это непоказательно по очевидным причинам — тестируется же накопитель, а не его кэш! С другой — если за пределы кэша еще надо ухитриться выйти, то какая разница, какая там скорость за его пределами, если ее мы никогда почти не увидим?

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