Падение скорости чтения с ssd для файлов, записанных N месяцев назад

время сохранения заряда в ячейках SSD очень небольшое (по сравнению с жизнью магнитных доменов в hdd). конденсатор тупо разряжается - информация теряется.
для ентого в аппаратуру носителя внедрена прибавка к данным в виде кодов восстановления рида-соломона, чтобы «если чё» восстанавливать разрядившиеся байтики.
если при чтении в блоке найдена ошибка, она восстанавливается и отправляется потребителю, а ущербный блок перезаписывается во избежании порчи данных, ясен пень.
на это и уходит время и скорость чтения тормозится.
вывод очень давний - не хранить на SSD важные данные длительный срок в холодную.
вариант2 еще слышал: периодически «прогревать» SSD (прям тёплый ламповый звук :) подключением питания…

использую как переносно

Контроллер периодически сканирует данные и в фоне обновляет нестабильные сектора. Если диск всё время выключен, то будет вот как выше написано.

В теме на ixbt у юзера WD blue был диском D:, всё время подключенным. Так что от этого не зависит.

у сестры моей бабушки…

Вообще не показатель что там у юзера на ixbt было.

Т.е. некому юзеру с ЛОР-а ты доверяшь, а юзеру с IXBT нет?

Здесь не в доверии дело.

а если приложением Disks прогнать тест скорости чтения?

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

Я тоже думал, что перезаписывается. Но оказалось, что вот как минимум на Samsung 970 EVO накопитель сам не перезаписывает сбойные блоки, которые всё же удалось прочитать. Мне пришлось это делать явно.

QLC с кешем?

PLC с TLC кэшем кек

TLC

В годы его производства ssd с QLC в продаже еще замечены не были.

Там есть ссылка на выдачу smartctl

233 NAND_GB_Written_TLC     -O--CK   100   100   ---    -    771
234 NAND_GB_Written_SLC     -O--CK   100   100   ---    -    1009
241 Host_Writes_GiB         ----CK   253   253   

А падения скорости чтения для не сбойных файлов не наблюдалось?

Не знает ли кто инструмент аналогичный упомянутому выше SSDReadSpeedTester (он под оффтопик)? Данное приложение читает файлы (чтение просто поверхности менее разумно; хочется сопоставить момент времени, в который был записан файл и скорость его чтения) с определением скорости чтения для данного файла.

Уж больно узкий случай. По крайней мере, первая часть со сбором данных. Проще будет её накостылить на скриптах. Например, так:

find /var -type f -size +33554431c 2>/dev/null | while read f; do
    speed=$(LANG=C dd if="$f" of=/dev/null bs=32M iflag=direct 2>&1 | tail -1 | awk '{print$(NF-1), $NF}')
    modtime=$(stat -c "%Y" "$f")
    echo "$modtime $speed $f"
done

Для дальнейшего анализа наверняка что-то есть готовое хотя бы в том же LO Calc. Или в R. Или в Octave. Или даже в Gnuplot.

Мне кажется, что нет. Давно было, я уже подробности может и забыл. Я в конечном итоге стал просто дампить содержимое напрямую с блочного устройства. Там скорости чтения в ddrescue были хорошие, но на некоторых блоках чтение просто абсолютно затыкалось.

век живи - век учись - все равно дураком помрёшь…

Кстати, вот темы про сбойные SSD:

• [жж] словил сбойные сектора на nvme ssd
• наткнулся на сбойные сектора на очередном nvme ssd

ну вполне может быть рукожопие производителя прошивок, который просто забыл включить background media scan…

такое скорее всего тогда, когда в блоке какой-то из секторов не читается. хотя все равно странно - по идее из него нормально читаемые сектора должны были бы быть перемещены в другой блок… вероятнее всего баг прошивки.

У меня лежит X240 с ssd которую не включал сто лет в обед. Все живо. Куча флешек. Конденсатор разряжается при попытке считать его заряд - это некий макро-аналог принципа неопределенности. Пока конденсатор заряжен - он заряжен. Но пытаясь измерить его заряд вы вносите некоторое изменение в структуру конденсатора которое ускоряет утечку заряда.

И лежит много HDD в коробочках с древних времен - многие выбросил. Включаешь - тук-тук-тук головкой. И все. И ничего.

просто забыл включить background media scan

А ты всё не унимаешься с этим background media scan. Прямо такая уверенность, что он есть, хотя регулярно появляются свидетельства его отсутствия.

Видимо, тебе попадались только нерукожопые производители SSD. И получается, что ни Samsung, ни Western Digital к ним не относятся. Какие покупать-то? В каких этот BMS всё-таки есть?

fstrim делаешь на этом ssd? У меня было сходный случай, когда я засунул nvme ssd в коробочку и писал на него через usb-c. Записал, стер, записал пару-тройку сотен гигабайт, и он у меня начал сильно тормозить (скорость записи упала где-то в 10 раз). Пришлось найти, как сделать fstrim через usb-c, и после этого он начал опять работать как обычно.

fstrim делаешь на этом ssd

Не все коробочки умеют в trim…. Точнее - очень мало коробочек умеют в trim. А еще точнее - даже те мало коробочек которые умеют в trim в принципе требуют под онтопиком некоторых плясок с бубном.

ssd которому столет в обед, еще тебя переживет :) там предположу еще slc mlc, а они отличались живучестью по сравнению с современными.
с каждым повышением степени дробления заряда slc, mlc, tlc, qlc количество перезаписей падает в десять раз, длительность сохранения заряда в ячейке думаю и того хужееее…
так что нонешние носители не чета «каменным топорам» древности :)

заряд хранится в двойном затворе МОП-транзистора, сейчас мож что-нить помудреннее, но считывается производится через измерение проводимости канала онного МОП-транзистора.
т.е. измеряется не сам заряд, никаких воздействий на него не происходит, считывается проводимость канала, на который воздействует заряд.

я не про механику :) я про длительность сохранения состояния ячейки памяти…

mlc. Slc уже давно экзотика.

считывается производится через измерение проводимости канала онного МОП-транзистора

Обращаемся к классике то есть к коту шредингера. Чем ближе мы к квантовому размеру тем больше играют разные туннельные эффекты. Считвая «проводимость канала» мы должны подать туда напряжение -а значит где-то там будет более тонкий барьер через который что-то прыгнет. Прыгнуть конечно может в обе стороны - но вероятность прыжка в сторону уменьшения заряда гораздо выше чем в сторону увеличения.

Я бы тогда подключил этот SSD по SATA интерфейсу (насколько я понял, это SATA SSD), загрузился с какого-нибудь live usb и сделал ему трим.

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

Существует «read disturb», который может испортить содержимое соседних ячеек. Число «безопасных» чтений начиналось с миллионов для SLC, но постепенно снижается с развитием технологий. В первой же статье, которую можно нагуглить, заявляется, что для некоторых образцов MLC число безопасных чтений измерялось уже десятками тысяч, а не миллионами. Могу предположить, что с TLC и QLC ситуация стала только хуже.

Но вообще проблема известная, и вот за ней контроллеры флеш накопителей уже следят, скорее всего. Я надеюсь.

В теме на ixbt у юзера WD blue был диском D:, всё время подключенным. Так что от этого не зависит.

Так чтобы перезарядить ёмкость затвора полевого транзистора каждой ячейки флэш-памяти необходимо перечитать весь накопитель данных целиком. Одной подачи электропитания, конечно же, недостаточно.

QLC

Брать себе QLC можно только если себя сильно не любишь. Раньше вот носили всякие ошейники, лупили себя полетками до крови… Теперь люди с подобными отклонениями покупают QLC диски. Но индустрия идет вперед - PLC не за горами. Надежность ужасная, скорость никакая, а разница в цене - один раз в шоколаднице кофе с тортиком поесть и то не факт что хватит.

Ну бери SLC, кто мешает… А, стоп. Точно же, SLC сейчас не купишь.

Вот так скоро и QLC будет практически везде, без возможности взять что-либо другое. Не запасёшься же SSD’шниками на всю жизнь.

Мне пришлось это делать явно

Коим образом?

В первый раз dd со смещением чтобы записать ровно нужный участок. В следующий раз просто снял образ всего накопителя, сделал TRIM на весь объём, записал образ обратно.

хех, надо ужастнутся и найти тесты данного вида накопителей :)

А не вариант накостылить какой-то скрипт, который сделает find /some_mount возьмет каждый файл, запишет его в ram, сделает ему crc, потом запишет обратно и так каждый файл. А в конце прочитает все файлы и сверит их с crc. Получилось бы типа прогрева ssd =)

А вообще, можно было бы на сделать свою функцию mycp\mymv, которая бы при копировании формировала рядом с файлом crc. Так можно было бы всегда критично важные файлы чекать по crc

Контрольные суммы для данных реализованы в btrfs/zfs (bcachefs?)

Вот так скоро и QLC будет практически везде, без возможности взять что-либо другое.

Какбы нет. MLC Очень быстро вытеснили SLC. TLC потребовалось куда больше времени чтобы вытеснить MLC. И так по аналогии мы бы уже должны были радоватья QLC и PLC в бюджетном сегменте. Ан нет. QLC - до сих пор бюджетное говно, PLC - ну вроде как заявлено что уже разработано, но пока не встречал в продаже.

Тут физику не обманешь - каждый новый бит в два раза уменьшает разность потенциалов между состояниями, то есть мы имеем экспоненциальное по сути ухудшение надежности и скорости. А вот в емкости получаем +1 бит. SLC - 1бит, 100 тасяч циклов. MLC - 2 бит, 5000 циклов. TLC - 3 бит, 3000 циклов. QLC - 3 бит, 1000 циклов. Это только ресурс. А еще и надежность хранения. Как к сбоям, так и просто к стеканию заряда со временем. Соответственно этот 4-й бит требует основательно усложнить контроллер которому надо тщательнее следить за потерей данных и исправлять ошибки - соответсвенно хранить больше избыточной информации для коррекции.

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

И к тому же QLC нынешние совершенно не годятся для применения на серверах - то есть производитель так или иначе не снимет TLC чипы с производства, а раз будут чипы - то будут и пользовательские девайсы на них. Пусть дороже с каким-нибудь индексом Pro, но таки будут.

Правда очень высокая вероятность что именно QLC чипы будут активно распаивать по материнкам ноутов - замена ссд конечно дело прибыльное но иметь откровенный расходник превращающий в тыкву весь девайс целиком - гораздо привлекательнее.

В первый раз dd со смещением чтобы записать ровно нужный участок.

Зачем смещение? SSD это не жесткий диск, куда реально лягут данные решает контроллер и ему на все потуги что-то сместить или переместить немного покакать. Всеравно сделает по своему. Все эти дорожки и сектора пытющиеся представить ОС некое подобие обычного магнитного диска в реальности не существуют.

В следующий раз просто снял образ всего накопителя, сделал TRIM на весь объём, записал образ обратно.

Отличный рабочий вариант.

Зачем смещение?

Потому что если я запишу данные, которые прочитал по смещению, скажем, в 1e11, в самое начало накопителя, то есть посмещению 0, то у меня по факту просто таблица разделов слетит.

SSD это не жесткий диск, куда реально лягут данные решает контроллер и ему на все потуги что-то сместить или переместить немного покакать. Всеравно сделает по своему. Все эти дорожки и сектора пытющиеся представить ОС некое подобие обычного магнитного диска в реальности не существуют.

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

Этот скрипт сломается на чтении сбойного файла. В попытках это как-то преодолеть со временем получится реализовать аналог ddrescue. И в чём тогда смысл, если ddrescue уже есть и вполне с задачей справляется?

Просто представь, что происходит страницей, когда я записываю поверх неё новые данные

Когда записываешь на SSD - нет никакой гарантии что это будет та же физическая страница. Это может быть свободная область на чипе совсем в другом месте - в которую контроллер ССД решит записать данные а потом через свой внутренний маппинг просто перенаправит обращения ОС к этой «странице» на новое место. А может быть и поверх запишет - но вероятность невелика.

При записи на ССД через dd произойдет примерно следующее - сначала данные польются в slc кэш. Это опять же некая выделенная область тех же TLC ячеек (или QLC?) переключенных в slc режим. Параллельно с этим контроллер будет неспешно переклыдвать данные в длительное хранение перепаковывая их в свободные ячейки в уже QLC/TLC режиме. И после формального завершения копирования этот процесс продолжится - пока не разложится весь slc кэш. Опять же в отличии от hdd ssd не может записать «поверх». Сначала нужно обнулить ячейку - то есть тот самый trim. Если trim не сделан заранее и оттримленных блоков нет - то ссд будет это делать на лету - трим, потом запись блока. Ну и потом надо будет обновлять постоянно внутренний маппинг - чтобы OC если она вдруг захочет прочитать ту страницу которую она только что (или немного назад) записала - могла прочитать обратно. Независимо от того где эти данные физически - в slc кэше или уже перенесены на место постоянного хранения.

Если я не ошибаюсь, trim через usb-переходник не работает. Подключи через сата и сделай trim.

1. Подумай, как trim может влиять на скорость чтения (не записи) уже записанных файлов. (Команда trim — это не волшебная палочка, она выполняет строго определённую функцию, говорит контроллеру, какие ячейки уже не используются и их можно включить в пул свободных. Кстати, на этом диске всегда было немало свободного места (~25%), и с год назад на нём выполнялся trim через sata.)

2. Посмотри случаи по ссылкам, там всё в основном про установленные внутри диски.

my 2 year old «Kingston KC3000 M.2 2280 4096GB PCIe 4.0 x4 NVMe 3D TLC Internal Solid State Drive

Опять же в отличии от hdd ssd не может записать «поверх».

Только можно добавить, что современный hdd нередко с технологией SMR, а всё описанное таких дисков тоже касается.

(исправил опечатку)

простой пример: есть кингсшлак А400. у которого после лежания полгода на полке в редкоиспользуемом ноуте скорость чтения падает до вообще неприличных 800 КБ/сек - т.е. через год с него, уверен, вообще ничего бы не читалось.

если в нем нет BGMS - где массовые жалобы на потерю резко используемых данных (фоточек и т.п.) данных на нем и ему подобных? что, нет? отож…

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

опять же, тесты на затирание до дыр то ли на ixbt то ли где - после отлеживания 2 недели на полке ссд, оставленные в покое, внезапно начинали набирать бэд-блоки в смарте. без операций чтения. магия, не иначе :)

Зависит от конкретной железки. Одни умеют, другие нет.

Трим может высвободить много последовательных блоков, которые в таком виде читаются сильно быстрее чем с жонглированием мелко нарезанным FTL.

тут с ресурсом интереснее получается, ресурс сильно зависит от алгоритмов коррекции ошибок. и тот самый скачок TLC с ~500 циклов до 3000 во многом произошел не из-за новшеств в техпроцессе, а из-за внедрения LPDC который куда лучше корректирует ошибки…

ресурс сильно зависит от алгоритмов коррекции ошибок

Возможно - но опять же сомнительно. Ресурс упирается в деградацию самой структуры. Ну оно понятно что чем лучше корректируются ошибки - тем больше толерантность диска к этой деградации. Но как я понимаю по результатам тестирования дисков до полного отказа ресурс заявленный производителем «заканчивается» с запасом - то есть до того как коррекция ошибок начинает играть ключевую роль.

А вот по TLC c 500 до 3000 - всетаки не с 500 в а где-то с 1000. И переход произошел не с коррекцией ошибок а с переходом на многослойную 3Д флэш. Если посмотреть ресурс планарного и 3д флэша это заметно. Причина банальна - планарный флеш шел по уменьшению нанометров - а чем меньше нанометров тем менее выносливая структура. А в 3д сами ячейки стали сильно крупнее.

Трим может высвободить много последовательных блоков

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

Как написано выше

Опять же в отличии от hdd ssd не может записать «поверх». Сначала нужно обнулить ячейку - то есть тот самый trim. Если trim не сделан заранее и оттримленных блоков нет - то ссд будет это делать на лету - трим, потом запись блока.

Вспомнил — были данные по чтению очень фрагментированных файлов с ssd.

On two large .iso files (the slow one has been fragmented to 400,000 pieces, the fast one has a single fragment)
(400 тысяч фрагментов!)

https://www.overclock.net/threads/yes-file-system-fragmentation-does-affect-ssd-read-speed.1538878/

Скорость чтения падает с 506 до 159 МБ/с. Но никак не до 10 МБ/с.