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

баг конкретной фирмвари конкретного накопителя.

В моём случае были две модели, правда одного производителя, Samsung. Если погуглить ««media errors» ssd», можно найти репорты об аналогичных проблемах на накопителях других производителей.

расскажите же, как такая магия могла случиться если нет фоновой перезаписи…

Контроллер откалибровал опорные напряжения, например.

Кстати, на этом SSD за эти несколько часов увеличилось значение счётчика записанных данных в отчёте SMART?

возьмите обычные microsd карты, где никакого bgms нет

Какой в этом смысл? Допустим, будет потеря данных. Как это отнести к SSD? Возможно, дело будет просто в разном качестве флеша.

что её мешает уводить накопитель в сон сразу после чтения

В принципе, да. Но ведь чипы флеш-памяти всё равно греются.

А почему у того или иного накопителя не работает фоновое сканирование и перезапись блоков никто никогда не узнает.

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

Нет.

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

ещё их количеством, а значит шириной шины

Кстати, на этом SSD за эти несколько часов увеличилось значение счётчика записанных данных в отчёте SMART?

не смотрел, да и смысла не было - оффтопик сразу начинает качать 100500 обновлений…

для ссд используют особый, волшебный флэш, который не теряет данные? :)

Толерантность к числу ошибок может быть разная. В 32G флешку вполне можно вставить 64G чип, у которого 10% ячеек изначально мёртвые. Встроенный в чип контроллер на ходу разберётся, что к чему. В среднего размера microsd картах и USB-флешках наверняка даже один раз флеш не прочитывается на заводе. На это же время уходит.

оффтопик сразу начинает качать 100500 обновлений…

Эм… То есть было много не фоновых записей.

Значит у тебя такие кейсы

накопители делают

Ну это очень обобщённая формулировка. Там не хватает «все накопители» или «некоторые накопители», «делают всё время» или «в определённых обстоятельствах».

Вобщем, будем ждать реверса прошивок :)

Много чего не понятно, с одной стороны, вроде как, накопитель старается выровнять износ ячеек, то есть, при интенсивной записи, ячейки, в которые давно не было записи, будут задействованы, перезаписаны. С другой стороны, самые давно не изменяемые данные на накопителе, ИМХО, обычно не файлы, а таблица разделов, загрузчик, может какой суперблок ФС. И для обычного пользователя повреждение этих данных равносильно «всё пропало». То есть должна быть куча сообщений, что тот или иной накопитель лютое Г, типа выключил комп на пару месяцев и все фоточки пропали.

С другой стороны, самые давно не изменяемые данные на накопителе, ИМХО, обычно не файлы, а таблица разделов, загрузчик, может какой суперблок ФС. И для обычного пользователя повреждение этих данных равносильно «всё пропало». То есть должна быть куча сообщений, что тот или иной накопитель лютое Г, типа выключил комп на пару месяцев и все фоточки пропали.

В общем-то есть аппноты от брэндовых производителей с разбором параметров, влияющих на время хранения (вот прямо чтоб конкретной информации они само собой не дают, но ориентировочные псевдостатистические графики рисуют). И получается такая картина, что сильнее всего на деградацию врмени хранения влияет интенсивность использования диска/чипа, а точнее - таки записи. Условно говоря, если от сильно насилуемого диска по стандартам JEDEC требуется обеспечить 3 месяца или год (в зависимости от условий эксплуатации) хранения данных, то согласно этим аппнотовским графикам при околонулевой интенсивности использования (соотвественно речь больше о количестве перезаписей), то время хранения достигает многих лет, а то и переваливает за десяток (это данные слегка устаревшие, по qlc пока мало информации)

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

записанных пару лет назад. Скорость чтения по ходу процесса менялась в диапазоне от 8 до 15 МБ/с, не выше.

Интересно, будут ли жалобы на жёсткие диски, где при производстве записываются параметры треков для блинов (RRO) в NAND (вроде, 64 GB, но ещё и для других целей). WD рекламирует OptiNAND для 20+ TB. От тошибы и сигейта на этот счёт ничего не слышал.

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

записал инфу в блок - не трожь.

Да, но тогда при интенсивной перезаписи части объёма накопителя будет неравномерное количество циклов у разных блоков. Это опять приблизит кончину накопителя. ИМХО, по логике, если контроллер видит, что у какого-то блока 20 циклов стирания, а у другого 2, он должен решить, что там где 2 цикла, там редко изменяемые блоки и переместить их в блок, где 20 циклов. Ну, то есть в какой-то момент самые редко изменяемые данные оказываются в самой изношенной ячейке, иначе как износ выровнять.

ИМХО, по логике, если контроллер видит, что у какого-то блока 20 циклов стирания, а у другого 2, он должен решить, что там где 2 цикла, там редко изменяемые блоки и переместить их в блок, где 20 циклов.

Это не так просто. При следующем включении контроллер увидит, что у одного блока 21 цикл, а у другого 3 и переместит данные обратно)

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

Допустим, по спецификации флешка должна держать данные 5 лет. Фоновое сканирование проходит весь диск за месяц. А какая то ячейка теряет данные за пару дней… Вывод: просто битая ячейка, не повезло.

ИМХО, по логике, если контроллер видит, что у какого-то блока 20 циклов стирания, а у другого 2, он должен решить, что там где 2 цикла, там редко изменяемые блоки и переместить их в блок, где 20 циклов. Ну, то есть в какой-то момент самые редко изменяемые данные оказываются в самой изношенной ячейке, иначе как износ выровнять.

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

Это решает в том числе проблему, упомянутую вашим собеседником:

Это не так просто. При следующем включении контроллер увидит, что у одного блока 21 цикл, а у другого 3 и переместит данные обратно)

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

Допустим, по спецификации флешка должна держать данные 5 лет. Фоновое сканирование проходит весь диск за месяц. А какая то ячейка теряет данные за пару дней… Вывод: просто битая ячейка, не повезло.

Производители дружно забили на этот параметр. Если раньше сплошь и рядом в даташитах было что-то типа «Uncycled data retention: 10 years 24/7 @ 70°C», то сейчас пишут «Data retention: JESD47G-compliant; see qualification report», то есть вместо более менее-строгого указания минимального срока службы отделываются неким среднестатическим параметром (и то не слишком жирным)

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

echo "$modtime $speed $f"

Оно в секундах выводит, похоже.

(попробовал скрипт, работает)))

В принципе, есть новая прошивка, возможно в ней есть фоновое сканирование

https://smarthdd.com/rus/database/WDC-WDS250G2B0A-00SM50/

X61190WD

Update. Это прошивка от производителя контроллера…

https://community.wd.com/t/2-wd-blue/253255/2

https://forum.ixbt.com/topic.cgi?id=11:49444:0

Случайно наткнулся на этот пост. Есть диск, деградирует скорость.

WDC WDS500G2B0A-00SM50 500,1 GB 401000WD
Давно записанная (год и более) информация читается со скоростью 5-10Мб\с, если удалить и перезаписать информацию, то скорость восстанавливается. Подскажите, эту проблему можно решить программным методом?

не разберется. чип не в курсе, насколько быстро стекает заряд.

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

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

ну были записи. пускай и не так чтобы прям много (на порядки меньше чем SLC кеш). и? это как-то обьясняет почему случилась просадка до 800 кб/сек?

Дело не в том, что наличие команд на запись с хоста не объясняет всё. Дело в том, что их наличие размывает роль фоновой перезаписи, даже если она есть. К тому же у тебя показания гуляют:

пускай и не так чтобы прям много (на порядки меньше чем SLC кеш).

То там были записи, поэтому не ясно, увеличился счётчик записей от записей с хоста или контроллер там учёл инициированную прошивкой запись. То есть записей было так много, что на этом фоне не заметить, как прибавился целый объём накопителя. А теперь оказывается, что записей было на порядки меньше, чем даже SLC-кеш, который сколько там, треть? То есть одна тридцатая объёма накопителя. Сейчас ты вообще просто придумаешь новые симптомы, которые даже разработчики прошивки твоего SSD не смогут объяснить.

почему случилась просадка до 800 кб/сек?

У меня был опыт только с одним экземпляром Kingspec. Он от случайных записей мог зарезать чтение до двух мегабайт в секунду. То есть если большие файлы пишешь, то всё нормально. Пишешь много мелких — и даже чтение затыкается. В особо запущенных случаях может вообще в себя так надолго уйти, что хост считает, что накопитель умер. И для этого ему даже на полке лежать не потребовалось.

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

На данном WD Blue ssd скрипт показал скорость чтения файлов от 3.9 до 7.5 МБ/с.

Запустил badblocks -b 4096 -svn /dev/sda5. К сожалению, без time. За ночь отработал на разделе ~200ГБ (заполнен на ~70%). Ошибок не нашёл. Теперь скрипт чтения показывает скорость чтения 400-500 МБ/с для тех же файлов.

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

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

а откуда такие выводы, что прибавился целый обьем?… какбы ссд и так на 3/4 пустая была, гигов 60 или сколько там под оффтопик + кой-какой софт. и далеко не все блоки читались медленно. оценить сколько прилетело апдейтов за полгода (2 гига, или 5), какой был write amplification (пушо апдейт - это не только скачать, это еще извлечь файлы и записать их, или не извлечь а пропатчить имеющиеся, а еще может что-то поправить в реестре) и сколько в итоге дописало в фоне - навряд удастся оценить. не говоря уже о том, что в смарте фигурирует Host LBA writes (который по определению не будет расти от фоновых операций), ну и wear leveling ячеек…

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

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

какбы ссд и так на 3/4 пустая была

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