LINUX.ORG.RU

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

 , , , ,


1

4

Есть у меня ssd (WD blue 250GB), использовал примерно три года как переносной. Решил на днях переписать с него пару больших архивных файлов, записанных пару лет назад. Скорость чтения по ходу процесса менялась в диапазоне от 8 до 15 МБ/с, не выше. Думал, у меня проблема с USB адаптером. Специально записал на этот ssd ещё один файл, отсоединил-присоединил (для сброса кеша), скорость чтения примерно как и должна быть, ~350 МБ/с. Прочитанные с низкой скоростью файлы не битые, рядом с ними есть файлы с контрольными суммами sha256, всё совпало.

SMART: https://bpa.st/DTDQ

(SMART снят напрямую через SATA, установил этот ssd в старый ноутбук)

Про проблему (которой лет 10) с Samsung 840 EVO читал. Но ту проблему вроде разрешили прошивкой. И там был счёт на месяцы, у меня пара лет прошла.

Дальше преимущественно результаты гугленья

Есть довольно старая тема (цитировалась на ЛОР-е; 2014 года; свежие коменты от 2023)

Read speeds dropping dramatically on older files; benchmarks needed to confirm affected SSDs

https://www.overclock.net/threads/read-speeds-dropping-dramatically-on-older-files-benchmarks-needed-to-confirm-affected-ssds.1512915/?sortby=newest#replies

WD Blue 3D NAND: Loss of performance reported when reading old files
Jun 11, 2022

https://allinfo.space/2022/06/11/wd-blue-3d-nand-loss-of-performance-reported-when-reading-old-files/

Western Digital SSDs experiencing read performance degradation

https://linustechtips.com/topic/1275489-western-digital-ssds-experiencing-read-performance-degradation/

В этих темах используют SSDReadSpeedTester (под оффтопик)

Инструмент для чтения файлов с диска с определением скорости чтения.

И ещё:

SSDs that don’t slow down reading old files?
While the 840’s and the Corsair model dropped like a rock after ~3 months, WD model looks to appear to slow down gradually from 4 months to a year and maintain decent speeds.

https://www.reddit.com/r/unRAID/comments/10bi4sc/ssds_that_dont_slow_down_reading_old_files/?rdt=40849

I had what I believe to be the same issue with my 2 year old «Kingston KC3000 M.2 2280 4096GB PCIe 4.0 x4 NVMe 3D TLC Internal Solid State Drive (SSD) SKC3000D/4096G» I had some old VM images on the drive and attempting to read them would always result in the files reading extremely slowly (around 10 MB/s) but if i copied a new file to the drive and then read it back it would read at the expected fast speed of about 2.5 GB/s.

Тема, где аналогичные жалобы на WD Blue, Kingston A400:

https://forum.ixbt.com/topic.cgi?id=4:142795

Вопрос (если кто-то дочитал до конца):

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

★★★★★

Последнее исправление: greenman (всего исправлений: 18)

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

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 2)
Ответ на: комментарий от MagicMirror

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

greenman ★★★★★
() автор топика
Последнее исправление: greenman (всего исправлений: 1)
Ответ на: комментарий от pfg

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от t184256

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   
greenman ★★★★★
() автор топика
Последнее исправление: greenman (всего исправлений: 1)

Не знает ли кто инструмент аналогичный упомянутому выше 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.

i-rinat ★★★★★
()
Ответ на: комментарий от greenman

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

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

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

NiTr0 ★★★★★
()
Ответ на: комментарий от pfg

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

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

Qui-Gon ★★★★★
()
Ответ на: комментарий от NiTr0

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

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

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

i-rinat ★★★★★
()

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

rupert ★★★★★
()
Ответ на: комментарий от rupert

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

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

Qui-Gon ★★★★★
()
Ответ на: комментарий от Qui-Gon

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

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

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

pfg ★★★★★
()
Ответ на: комментарий от pfg

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

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

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

Qui-Gon ★★★★★
()
Ответ на: комментарий от Qui-Gon

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

pfg ★★★★★
()
Ответ на: комментарий от pfg

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от greenman

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

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

Enthusiast ★★★
()
Ответ на: комментарий от i-rinat

QLC

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

Qui-Gon ★★★★★
()
Ответ на: комментарий от Qui-Gon

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от serg002

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

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

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

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

serg002 ★★★
()
Последнее исправление: serg002 (всего исправлений: 1)
Ответ на: комментарий от i-rinat

Вот так скоро и 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 чипы будут активно распаивать по материнкам ноутов - замена ссд конечно дело прибыльное но иметь откровенный расходник превращающий в тыкву весь девайс целиком - гораздо привлекательнее.

Qui-Gon ★★★★★
()
Последнее исправление: Qui-Gon (всего исправлений: 1)
Ответ на: комментарий от i-rinat

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

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

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

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

Qui-Gon ★★★★★
()
Ответ на: комментарий от Qui-Gon

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

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

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от serg002

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

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

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

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

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

Qui-Gon ★★★★★
()
Ответ на: комментарий от Jeronimo
  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

greenman ★★★★★
() автор топика
Последнее исправление: greenman (всего исправлений: 2)
Ответ на: комментарий от Qui-Gon

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

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

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

greenman ★★★★★
() автор топика
Ответ на: комментарий от i-rinat

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

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

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

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

NiTr0 ★★★★★
()
Последнее исправление: NiTr0 (всего исправлений: 1)
Ответ на: комментарий от Qui-Gon

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

NiTr0 ★★★★★
()
Ответ на: комментарий от NiTr0

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

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

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

Qui-Gon ★★★★★
()
Ответ на: комментарий от MagicMirror

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

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

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

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

greenman ★★★★★
() автор топика
Последнее исправление: greenman (всего исправлений: 3)
Ответ на: комментарий от greenman

Вспомнил — были данные по чтению очень фрагментированных файлов с 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 МБ/с.

greenman ★★★★★
() автор топика
Последнее исправление: greenman (всего исправлений: 1)