An LBA (адреса логических блоков) - это таблица отображения, реализованная в FTL для сопоставления логических и физических страниц / блоков в SSDя думаю, что большинство SSD (по крайней мере, когда они пусты) сохраняет физические адреса в том же порядке, что и логические (физический адрес 0 отображается на логический адрес 0, 1 на 1 и так далее).
При изменении страницы SSD контроллер копирует обновленную страницу в кеш, изменяет страницу, помечает старую как 'нет действительных / несвежий', а затем напишите новый в другом месте и обновите LBA.
Итак, после пары операций записи, даже если физические адреса были выровнены с логическими, этот порядок будет нарушен!
Почему же тогда последовательная запись имеет лучшую производительность, чем случайная?
редактировать
Отсутствие производительности между последовательной и случайной записью было независимо от размера блока или глубины очереди.
Достаточно краткое объяснение Seagate о том, как сборка мусора отвечает за разницу в производительности SSD при случайной и последовательной записи:
... необходимость в сборке мусора влияет на производительность SSD, потому что любая операция записи на «полный» диск (тот, чье начальное свободное пространство или емкость были заполнены хотя бы один раз) должна дождаться доступности нового свободного пространства, созданного с помощью процесс сборки мусора. Поскольку сборка мусора происходит на уровне блоков, также существует значительная разница в производительности в зависимости от того, используются ли последовательные или случайные данные. Последовательные файлы заполняют целые блоки, что значительно упрощает сборку мусора. Для случайных данных ситуация совершенно иная.
Поскольку случайные данные записываются, часто несколькими приложениями, страницы записываются последовательно во всех блоках флэш-памяти.
Проблема в следующем: эти новые данные заменяют старые данные, распределенные случайным образом в других блоках. Это приводит к тому, что потенциально большое количество небольших «дыр» недопустимых страниц разбрасывается среди страниц, все еще содержащих действительные данные. Во время сборки мусора этих блоков все действительные данные должны быть перемещены (т.е. прочитаны и перезаписаны) в другой блок.
Напротив, при замене последовательных файлов целые блоки часто недействительны, поэтому перемещать данные не требуется. Иногда часть последовательного файла может разделять блок с другим файлом, но в среднем нужно будет переместить только около половины таких блоков, что делает это намного быстрее, чем сборка мусора для случайно записанных блоков. ...
Другое объяснение состоит в том, что последовательные операции ввода-вывода легче объединить на всех уровнях. Обычно у вас меньше накладных расходов, когда вы отправляете одни и те же данные, но используете меньше, но больше операций ввода-вывода, поэтому вы можете достичь более высокой пропускной способности за счет объединения. Вам нужно будет доказать, что какое бы ядро вы ни использовали, оно не разбивало ваши последовательные операции ввода-вывода на более крупные операции ввода-вывода, что уменьшало накладные расходы и улучшало производительность по сравнению с тем, что оно должно было делать для случайного ввода-вывода.