Почему у SSD падает скорость чтения при заполнении?

почему у некоторых SSD

У всех. Потому что так устроены SSD. Грубо говоря это хак для увеличения скорости, при котором используется свободное место. Нет свободного места, нет и скорости.

У всех

Нет.

PCIe

Да

Офигеть, не знал об этом. А что? Если оно свободным объёмом исключительно нули считает, то есть ли файловые системы, которые зануляют все освобождающиеся блоки?

Да, гугли discard и TRIM.

Нули это нули, а свободный объём это тот про который комп прислал команду что он свободный. Это не команда записи секторов а другая.

Пример: новый диск (dd zero) выдает 3200 МБ/c (800k IOPS)

Может быть это скорость только «для чтения нулей»?

А если заполнить рандомом 10% и читать именно эту область?

Зачем ты говоришь о том, чего не знаешь? SLC-кэш к чтению отношения не имеет.

Если для тестирования используется какая-то программа что читает случайные блоки на диске, не проверяя заняты ли они - то если блоки никогда не записывались или были помечены как пустые, то диск ничего не читает, просто возвращает нули (или 0xff байты). Поэтому до заполнения оно и работает быстро.

некоторые ssd еще и греться в простое начинают если заполнены более 90%

Trim не помогает?

Для самообразования. Вот я сказал что-то, если у меня ошибки, то я чему-то новому учусь, когда мне указывают на ошибки.

Есть ли свзять с памятью TLC или QLC?

Да. Одна ячейка QLC хранит 4 бита данных. Адресовать отдельные ячейки быстрее чем биты в них. Если у тебя носитель заполнен меньше чем на 1/4 то контроллер SSD может писать по одному биту в каждую QLC ячейку, и считывать так же. Как я понимаю по мере заполнения SSD QLC ячейки алгоритмически проходят эволюцию от SLC (1-бит/ячейка) до QLC(4-бита) c промежуточными остановками в MLC (2-бита) и ТLC (3-бита). Это мои теоретические размышления о работе контроллера, если я не правь поправьте.

Как я понимаю по мере заполнения SSD QLC ячейки алгоритмически проходят эволюцию от SLC до QLC c промежуточными остановками в MLC и ТLC. Это мои теоретические размышления о работе контроллера, если я не правь поправьте.

Тут всё зависит от представлений о прекрасном создателей контроллера частично тех, кто его использует в своих изделиях. Но не думаю, что есть промежуточные шаги. Вроде накопители просто в фоне сразу перепаковывают SLC-ячейки в свой основной режим — TLC или QLC. Наверное, скорость чтения может действительно пострадать, если диск сейчас очень занят своими внутренними делами и не может их отложить по объективным причинам или просто потому что производитель так решил. Тоже скорее домыслы, я не эксперт.

Такое вполне может быть, если производитель будет заморачиватсья надежностью. Вот только это снижает скорость обращения к данным, прочитать 1 блок по 4 бита быстрее, чем 4 по одному биту. То есть при заполнении скорость будет возрастать. Кто-нибудь купит такой диск и будет недоволен, что у дешевых китайских дисков без такой заботы - показатели лучше. Из-за этого вряд ли этим вообще кто-то занимается, потому что покупатели в первую очередь на скорость посмотрят и тут же отзывы поставят исходя из этого.

покупатели в первую очередь на скорость посмотрят и тут же отзывы поставят исходя из этого

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

Есть подозрение, что б/у чипы памяти (скоро сдохнут)

Не эксперт, но

новый диск (dd zero) выдает 3200 МБ/c (800k IOPS)

Это ты померил скорость общения с контроллером - контроллер знает все «пустые» блоки и реально ему не надо ничего считывать, чтоб тебе сообщить о пустоте.

после заполнения (dd urandom) на 100% выдает 520МБ/c (130k IOPS).

Это ты померил реальную скорость работы диска - все блоки заполнены, кеш не эффективен из-за рандома, считываем все блоки.

SLC-кэш к чтению отношения не имеет.

Да ладно. SLC кэш дает двукратный прирост к RND4K1T1Q.

хых, не то что битами, даже не байтами :) носители давно оперируют блоками от 512 байт до 4 килобайт.
уровени SLC-QLC определяются аппаратной схемой драйвера ячеек. он должен уметь записывать 2^n уровней заряда в ячейку и считывать 2^n уровней заряда из ячейки.
даунгрейд к меньшему количеству уровней возможен. апгрейд к большему числу уровней нет. только новую схемотехнику разрабатывать и настраивать.

Оказывается, действительно контроллер преобразует псевдо-SLC в TLS при использовании кэша.

вопрос: если slc-кэш заполнится в течение одного прогона записи, как в ваших тестах, как он освобождается в дальнейшем? упоминалось то, что сначала ячейки записываются в режиме slc, затем процесс записи переходит в режим tlc и mlc. интересно, есть ли какие-то процедуры самооптимизации, когда при простое контроллер перезаписывает данные из ячеек в режиме slc в ячейки режима tlc, уплотняя размещение данных на диске? может slc-кэш доступен всегда в районе 30% свободного места в пределах одного процесса записи, по исчерпании которого будет включаться режим mlc/tlc для записи в пределах этих же 30%? вот этот момент мне не понятен.

Да, режим миграции данных из зоны slc в tlc имеется и он называется «фоновым сбросом» (background flushing). Фоновый сброс реализуется контроллером самого SSD и это происходит тогда, когда диск менее всего нагружен или в целом находится в простое. У контроллера диска больший приоритет всегда отдается операциям чтения и записи. Про 30% - да, есть такое понятие как «динамическое slc-кэширование». Реализует это понятие, например, технология, которая называется Samsung Intelligent TurboWrite. Встречается сей редкий зверь в таких SSD как Samsung серии 970 EVO и 980 PRO. Если есть свободное пространство на диске, то контроллер диска динамически, параллельно процессам чтения и записи, может включать эмуляцию slc на tlc ячейках, таким образом поддерживая +- одинаковое количество % ячеек под slc кэш, что дает ещё более производительные результаты.

SLC кэш дает двукратный прирост к RND4K1T1Q

Пока ячейки не упакованы в QLC/TLC? Ну такое. Ты же в курсе, что SLC-кэш это те же самые 3/4-битовые ячейки, временно пребывающие в однобитовом состоянии?

Пока ячейки не упакованы в QLC/TLC?

Естественно.

Ты же в курсе

Естественно.

c промежуточными остановками в MLC (2-бита) и ТLC (3-бита).

Нет, без промежуточных остановок.

Естественно.

Ну и смысл тогда говорить про краткосрочный побочный эффект как про некую фичу? Чтобы этим воспользоваться, надо записать что-то, а потом быстро начать читать. Не уверен, что такие сценарии часто встречаются за пределами тестов.

краткосрочный побочный эффект

Почему краткосрочный? Пока свободного места достаточно, данные можно хранить в SLC форме.

Почему побочный? Прирост в однопоточном случайном чтении может даже на глаз быть заметен при первой загрузке чего либо.

за пределами тестов

Так это же самое главное, красивые циферки нужны для маркетинга.

Не нули, а то что явно очищено через discard. Явное зануление диска через что-нибудь вроде dd потенциально тоже может уронить производительность.

Почему краткосрочный? Пока свободного места достаточно, данные можно хранить в SLC форме.

Не буду врать, хоть каких-то обзоров SSD я давно не читал, но сомневаюсь, что много какие контроллеры/прошивки долго держат ячейки в SLC-режиме в течение долгого времени. Иначе, когда место понадобится, явно будет сильно страдать скорость записи из-за одновременной упаковки старых ячеек. Да и сам кэш часто слишком маленький, чтобы как-то его ощутить за пределами небольших объёмов записи.

Почему побочный?

Потому что SLC-кэш придуман для ускорения записи. Если он что-то даёт на чтении — это уже побочка, вряд ли кто-то делает ставки на этот эффект.

Так это же самое главное, красивые циферки нужны для маркетинга.

С этим не спорю, да вообще скоростей линейных чтения/записи с оговорками под сноской хватит :)

Тогда скорость падает меньше, но падает.

вряд ли кто-то делает ставки на этот эффект

Ставки на это действительно делать не стоит, так как достоверно не известно по каким алгоритмам это все работает.
И даже если взять диск большего объема и не использовать часть, то нет никакой гарантии что все будет в SLC.
К тому же и прирост, чего то не в два раза оказался, сейчас потестировал и получилось 50Mb/s vs 80Mb/s. Одному файлу два года и после него записаны терабайты, другому 1 день и после него записано несколько гигабайт.

Это ты померил реальную скорость работы диска - все блоки заполнены, кеш не эффективен из-за рандома, считываем все блоки.

Свежие данные: диск Kingspec XG7000 512 Гб.

lsblk /dev/nvme3n1
nvme3n1     259:11   0 476,9G  0 disk  
├─nvme3n1p1 259:15   0   256G  0 part  
└─nvme3n1p2 259:16   0 220,9G  0 part

dd if=/dev/urandom of=/dev/nvme3n1p1 oflag=direct (заполнили весь раздел)

Делаем TRIM у второго раздела (я только так умею):

mkfs /dev/nvme3n1p2
mount /dev/nvme3n1p2 /mnt
fstrim -v /mnt

/mnt: 217,4 GiB (233445986304 bytes) trimmed

Оставил на час… Читаем через fio:

[global]
ioengine=io_uring
iodepth=32
direct=1
numjobs=4
filesize=200g
size=200g
group_reporting

[random_read_32k]
rw=randread
blocksize=32k
filename=/dev/nvme3n1p1
stonewall

fio-3.38
Starting 4 processes
bs: 4 (f=4): [r(4)][0.7%][r=788MiB/s][r=25.2k IOPS][eta 16m:46s]

788 МБ блоками по 32k, 25000 IOPS.

эволюцию

деградацию

Вангую тред на овер 30 страниц.

Лишь бы по делу :) Все-таки в чем физика процесса уменьшения скорости чтения?

И желательно на примере QLC памяти на дисках с алишки.

Не понял, вы что с чем сравниваете:

[r=788MiB/s][r=25.2k IOPS]

520МБ/c (130k IOPS)

У вас разница между IOPs и байтами в с не пропроциональна.

По поводу, как получается 3200 на trim'нутых блоках вам уже ответили. Можете сейчас с помощью fio почитать второй раздел, которых тримнули.

Но, в целом, fio ничего интерестного не покажет. Нужен тест, который измерят скорость чтения каждого небольшого блока, ну, допустим, 1 Мбайт, и там уже можно медитировать над результатами. Хотя бы будет видно, относительно равномерно эти условные 800 МБ/с или какие-то блоки сильно медленее других. Воспроизводится ли разброс скорости при повторном чтении и т.д.

прочитать 1 блок по 4 бита быстрее, чем 4 по одному биту.

Почему? Компаратор медленее АЦП работает? Вроде, где-то писали, что у этих TLC, QLC и т.д. вобще есть несколько скоростей чтения, чем медленне, тем точнее измеряется напряжение ячейки. А дальше, ещё возможно, что в режиме SLC не потребуется коррекция ошибок. ЕМНИП, алгоритмы коррекции позволяют быстро определить, нужна корреция или нет, а для определения какие биты нужно переключить нужно много вычислений.

эволюция в цене :) мыж в коммерческом мира живем.
деградация в качестве: скорость и время сохранения данных :)

Знатоки есть. Есть SSD лежал на полке без использования 2 (джва) года. Если ща его врубить, работать будет норм? (работать, в смысле, с новыми данными).

Старые данные будут читаться очень медленно, возможно, не прочитаются. Лучше скопировать и записать заново.

Если он у тебя не окирпичился за время лежания, то по идее должен норм работать. Только желательно перед использованием привести его в чувство перезаписью всего объёма. А ещё лучше сделать ему secure erase.

Только желательно перед использованием привести его в чувство перезаписью всего объёма

Не нужно. Да и два года так себе срок.

А ещё лучше сделать ему secure erase.

Это же просто ротация ключа шифрования, ничего там реально не стирается.

Не нужно. Да и два года так себе срок.

Ну попробуй запиши что-нибудь на ссд и положи его на полку на два года. Если накопитель качественный и неизношенный, то может и не будет ничего, а вот если ссд уже поюзаный, то не факт что он вообще у тебя запустится. Вот, например, как ведёт себя ссд (правда уже запиленный) всего после месяца лежания на полке.

Это же просто ротация ключа шифрования, ничего там реально не стирается.

Это зависит от того, какой ключ ты укажешь при форматировании. Выжимка из руководства к nvme-cli:

0: No Secure Erase operation requested (generally speaking, this just TRIMs/deallocates all the LBAs)

1: User Data Erase – this physically erases the data on the drive. In a mainstream NAND NVMe SSD, this will trigger the erase of all the blocks as well as changing the cryptographic key. Due to the physics of NAND erases (consuming power and time) this can take some time (for large drives measured in single digit minutes)

2: Crypto Erase, this completes much faster (under 1 second in most cases) by swapping out the cryptographic key so that all data is rendered unreadable. Like all three cases, this will deallocate the LBAs and some drives may support deterministic read zero after TRIM for subsequent reads.

Т.е. с ключом «1» утилита не только очищает таблицу трансляции адресов, но и затирает все блоки, что равносильно перезаписи.

Это зависит от того, какой ключ ты укажешь при форматировании.

А, никогда не вникал особо, не было необходимости пока. Спасибо за уточнение.

протухание пустых/новых ssd (комментарий)

Вот ещё похожий случай помирания ssd от энергетического голода. Причём в отличие от 870-го Самсунга, прославившегося своей забывчивостью, тут судя по всему (если гугл не брешет) стоит ещё древняя MLC. Так что вот так, да.