Проблемы с дисками, восстановление данных, Жесткими, твердотельными, мягкотелыми, круглыми, квадратными Опции

[Allex]

Это что же получается, надо каждые 2-3 месяца восстанавливать этот SSD до заводских настроек?

Я бы поотключал в виндовозе всю "диагностику" и шпиономанию - тогда легче будет.

[Datarecover]

Вот только сейчас дошли руки, чтобы воспользоваться этим советом. До этого они были заняты разной ерундой, включая и ковид.
Secure Erase выполнил с помощью Kingston SSD Manager. До этого тест SSD был такой:
http://piccy.info/view3/14239423/15d6d3958...bfbef0e42ab2f29

Теперь он выглядит так:
http://i.piccy.info/i9/ccd3c5b255af6d4f953...420530/SSD1.jpg

Это что же получается, надо каждые 2-3 месяца восстанавливать этот SSD до заводских настроек?

у меня есть 500 от кингстона с похожими симптомами , так и живет с ирейсом (ну или пересчетом траслятора) раз в квартал, все никак не доберусь глянуть как это полечить. Мне кажеться что просто какой то из чипов подыхает. Или не пропаен. Но это так предположение.

[Allex]

у меня есть 500 от кингстона с похожими симптомами , так и живет с ирейсом (ну или пересчетом траслятора) раз в квартал, все никак не доберусь глянуть как это полечить. Мне кажеться что просто какой то из чипов подыхает. Или не пропаен. Но это так предположение.

Подыхающий чип SE не лечит, и пайку восстановить тоже не умеет - так что это точно не оно.

Если SE помогает - это означает только то, что у SSD сильно замусоривается транслятор большим количеством мелкоблочной записи при нехватке свободного пространства в флеше. Лечится сие - обеспечением свободного пространства (Over-Provisioning, Trim) и урезанием мелкоблочной активности виндовоза (десятка, установленная по умолчанию, пишет просто неприличную тучу логов).

[Datarecover]

Подыхающий чип SE не лечит, и пайку восстановить тоже не умеет - так что это точно не оно.

Если SE помогает - это означает только то, что у SSD сильно замусоривается транслятор большим количеством мелкоблочной записи при нехватке свободного пространства в флеше. Лечится сие - обеспечением свободного пространства (Over-Provisioning, Trim) и урезанием мелкоблочной активности виндовоза (десятка, установленная по умолчанию, пишет просто неприличную тучу логов).

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


Сообщение отредактировал Datarecover - Apr 22 2021, 10:55

[Allex]

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

Чтение тут ни при чем.

А вот мелкоблочная запись - очень даже при чем: она сильно фрагментирует транслятор, особенно если свободного места мало, и подкидываемые то в один лог, то в другой, то в Registry записи вызывают активную сборку мусора.

Поэтому SE чип не лечит но уменьшает количество обращений к нему и еще делает пересчет основного транслятора.

А нечего там пересчитывать - при SE транслятор просто тупо сносится весь и создается новый, как при первом включении.

[Datarecover]

Чтение тут ни при чем.

А вот мелкоблочная запись - очень даже при чем: она сильно фрагментирует транслятор, особенно если свободного места мало, и подкидываемые то в один лог, то в другой, то в Registry записи вызывают активную сборку мусора.

А нечего там пересчитывать - при SE транслятор просто тупо сносится весь и создается новый, как при первом включении.

Похоже мы говорим о разных трансляторах. Поэтому я не понимаю какое отношение имеют данные к транслятору ну кроме обращения к блоку. Задача Grown транслятора мапить блоки которые обслуживаюься с ошибкам. Основной транслятор определяет последовательность блоков. Но ни то не другое не зависит от данных , но в принципе зависит от интесивности работы от которой еа прямую записи частота возникновения ошибок. И мне совсем не понятно как транслятор может фрагментироватся. Но я полностью согласен с тем что на многих ССД буфер для обработки кандидатов маленький , а время пересчета транслятора большое , поєтому просто начинает возникать затык.

При SE производиться пересчет транслятора с учетом кандидатов и соответсвено список кандидатов очищается , во всяком случае на части ССД которые я смотрел. Но опять же все эти таблицы заполняются из-за нестабильных блоков если понять как их находить то можно просто менять/шатать глючный чип.

[Allex]

Похоже мы говорим о разных трансляторах.

По-видимому - таки да... ;+))

То, что хранит адреса сбойных блоков - это не транслятор, а просто таблица, в которой записано, какие блоки стирания "выключены из оборота".

Транслятор же - это структура, по которой контроллер ищет соответствие внешних LBA адресов и физических адресов размещения данных, записанных на эти LBA.

Когда что-то записывается линейно - то последовательные LBA оказываются рядом в одной странице записи и в одном блоке стирания, находить их быстро, потому что они оказываются в одном блоке транслятора. А вот когда начинается хаотическое дописывание строчек в кучу отдельно лежащих логов - то начинается шабаш: иало того, что переписывается сектор, в котором хранится "хвост" файла лога, так еще и переписываются сектора каталога, в которых хранятся свойства этого файла, правятся MFT, да еще и журнал. И все это - естественно, в разных LBA. Их данные записываются-то в одну или в соседние страницы записи, но так как эти LBA уже использовались - места, куда было записано их прежнее содержимое, становятся мусором, который нужно убирать - а это дополнительные перезаписи и, соответственно, разрастание транслятора.

[Datarecover]

По-видимому - таки да... ;+))

То, что хранит адреса сбойных блоков - это не транслятор, а просто таблица, в которой записано, какие блоки стирания "выключены из оборота".

Транслятор же - это структура, по которой контроллер ищет соответствие внешних LBA адресов и физических адресов размещения данных, записанных на эти LBA.

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

Но еще есть транслятор который помечает то что не нравиться для дальнейшей обработки и исключения или возврата в работу, это работает и на ХДД и на СДД. На ссд есть еще трансляция с замешиванием для того чтобы запись шла только в чистые страницы котрые предврительно очищает ТРИМ. И да эти здичи для диска боее приоритетны чем какието том данные пользователя , поэтому если диск занят то пользователь ждет, а если пользователь начнет еще и питание дергать то есть шанс что диск скукожиться.

[Datarecover]

Когда что-то записывается линейно - то последовательные LBA оказываются рядом в одной странице записи и в одном блоке стирания, находить их быстро, потому что они оказываются в одном блоке транслятора. А вот когда начинается хаотическое дописывание строчек в кучу отдельно лежащих логов - то начинается шабаш: иало того, что переписывается сектор, в котором хранится "хвост" файла лога, так еще и переписываются сектора каталога, в которых хранятся свойства этого файла, правятся MFT, да еще и журнал. И все это - естественно, в разных LBA. Их данные записываются-то в одну или в соседние страницы записи, но так как эти LBA уже использовались - места, куда было записано их прежнее содержимое, становятся мусором, который нужно убирать - а это дополнительные перезаписи и, соответственно, разрастание транслятора.

последовательные ЛБА не обязаны находиться рядом физически , их местоположение определяют таблицы трансляции.

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

Мы тут обсуждаем вопрос того что в следсвии работы падает линейная скорость а не файловая , значит файловую систему можно исключить. И мы выяснили , что она улучшается в следствии SE которое как уже обсуждалось сносит (персчитывает пересоздает ) Г (растущий) транслятор. Но в это транслятор попадают плохо читаемые блоки и он сам долго работает , вот и остаеться понять что их этого проблема софт обработки блоков (страниц) или наличие битого чипа. Если бы проблема была в софте то это былобы на всех устройствах этой серии , если в чипе то только на тех где он битый. Просто есть еще 1 фишка ссд отдает пустое место также как диски с черепичной записи на основании метки что страница чистая. А призаписи данные распределяться по разным чипам для скорости и вчислить какой чип битый я не знаю как. Ну рабочие идеи есть но только для ССД в котрых я могу генерить свой транслятор просто выводя из работы некоторые чипы , о до такой степени разобраных девайсов очень мало.

На пользовательском уровне советовать просто уменьшить нагрузки это конечно правильно и поможет , но как я уже говорил в такой ситуации диск нужно плавно перемещяться на полку или в корзину, где интенсивность его использования стремиться к 0.

[Allex]

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

На самом деле - нет.

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

Потому - в транслятор входят только те LBA, которые хотя бы раз уже использовались. Попробуй натравить чтение на только вытащенный из коробки (или только что после SE) SSD - и ты увидишь замечательную ровную линию максимальной скорости, если на SATA - так и вообще скорее всего ограниченную скоростью порта. А потом пропиши SSD данными - пусть даже линейно - и скорость сразу снизится. Та вот "скорость чтения" после SE - на самом деле ничего не читает. Пока транслятор пуст - обращение к SSD по любому LBA не требует отработки контроллером, он сразу же отдает на такой запрос нули. А вот когда транслятор уже содержит адреса использованных секторов - то при запросе на такой LBA контроллеру "нулями" отделаться уже не с руки, он должен отдать реальные данные, а для того - сходить в транслятор, вычислить, где они лежат, отдать команду на чтение страницы нужному кристаллу флеша, дождаться ее выполнения, выцепить из нее нужный кусок и только тогда ответить хосту. Соответственно - и скорость оказывается ниже.

Но еще есть транслятор который помечает то что не нравиться для дальнейшей обработки и исключения или возврата в работу, это работает и на ХДД и на СДД.

Не, то отдельная таблица, и, похоже, на большинстве SSD она вообще упрощена до предела. Блок перестал стираться - его пометили "мертвый" и больше не используют. А всякими "для дальнейшей обработки" не заморачиваются.

На ссд есть еще трансляция с замешиванием для того чтобы запись шла только в чистые страницы котрые предврительно очищает ТРИМ.

Trim ничего не очищает. Эта технология переводит данные в состояние "мусор". А очисткой занимается сборщик мусора отдельно.

И да эти здичи для диска боее приоритетны чем какието том данные пользователя

Отработка Trim - таки да: это команда очень объемная и "хранить ее до лучших времен" у контроллера просто негде. А сборка мусора - обычно идет в фоне и никому не мешает... Разве что прошивка "дохозяйствовалась" до того, что у нее закончился пул свободных для записи страниц: вот тогда все притормаживает сильнее - ведь кроме как записью, контроллеру приходится заниматься одновременно и сборкой мусора, чтобы расчистить блоки для продолжающейся записи.

поэтому если диск занят то пользователь ждет, а если пользователь начнет еще и питание дергать то есть шанс что диск скукожиться.

А вот не нужно питание дергать, пока накопителю не отдана команда "отключайся".

[Allex]

последовательные ЛБА не обязаны находиться рядом физически , их местоположение определяют таблицы трансляции.

Вот в этом-то и дело...

Фрагментациия файловой системы

Не, то вопросы файловой системы, они нас пока не интересуют.

И на работуалгритма размещения файлов и журналирования внутрении структуры диска не влияют также и на оборот диску пофиг какая у него файловуха.

Не совсем пофиг. При дописывании стобайтной строчки в конец файла на FAT на накопитель уйдет перезапись в лучшем случае двух, в худшем - пяти LBA. А вот на NTFS - минимум будет четыре, насколько мне помнится, а максимум - десятки, если файловая система еще и в боковые потоки что-то дописывает при этом.

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

Точно.

И мы выяснили , что она улучшается в следствии SE которое как уже обсуждалось сносит (персчитывает пересоздает ) Г (растущий) транслятор.

Точно. Сносит. И пока на SSD не было ни одной записи - транслятор вообще пустой, и к флешу никаких обращений не идет.

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

Наличие полностью битого чипа выглядит совсем по-другому. Так как объем чипа значительно больше резерва блоков записи, выделенных под замену, то при такой неисправности SMART тебе скажет, что "блоков под замену больше нету, жизни у SSD осталось 0%".

Если бы проблема была в софте то это былобы на всех устройствах этой серии

Еще раз... Это проблема не в софте, а в разветвленности и фрагментировании транслятора. Это не плоская таблица (поиск по ней достаточно накладен в плане ресурсов контроллера), а некая более сложная структура. И количество саязнй в этой структуре растет по мере ее увеличения и фрагментации. А если SSD еще и "безбуферный", когда за каждой порцией транслятора нужно ходить в флеш - то вот и получается, что для чтения одного LBA контроллеру приходится физически прочитать несолько десятков мегабайт с флеша. Сооответственно - падает скорость.

На пользовательском уровне советовать просто уменьшить нагрузки это конечно правильно и поможет , но как я уже говорил в такой ситуации диск нужно плавно перемещяться на полку или в корзину, где интенсивность его использования стремиться к 0.

Отнюдь. Я на своих SSD изначально оставляю порядка 10-15% пользовательского объема неразмеченными (это гарантирует постоянное наличие свободного пространства и меньшее усиление записи, и, соответственно, меньшую фрагментацию трансляторов в результате), и с такими трудностями пока не встречался ни разу. И те мои знакомые, которые на эти грабли уже наступили, но сделали так же как и я, а дополнительно - дали по рукам десятке (я ею вообще не пользуюсь) - тоже годами таких проблем не испытывают.

[Datarecover]

На самом деле - нет.


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

ну да а кто тогда передет нам не полный обьем в ЛБА

Потому - в транслятор входят только те LBA, которые хотя бы раз уже использовались. Попробуй натравить чтение на только вытащенный из коробки (или только что после SE) SSD - и ты увидишь замечательную ровную линию максимальной скорости, если на SATA - так и вообще скорее всего ограниченную скоростью порта. А потом пропиши SSD данными - пусть даже линейно - и скорость сразу снизится. Та вот "скорость чтения" после SE - на самом деле ничего не читает. Пока транслятор пуст - обращение к SSD по любому LBA не требует отработки контроллером, он сразу же отдает на такой запрос нули. А вот когда транслятор уже содержит адреса использованных секторов - то при запросе на такой LBA контроллеру "нулями" отделаться уже не с руки, он должен отдать реальные данные, а для того - сходить в транслятор, вычислить, где они лежат, отдать команду на чтение страницы нужному кристаллу флеша, дождаться ее выполнения, выцепить из нее нужный кусок и только тогда ответить хосту. Соответственно - и скорость оказывается ниже.

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

Не, то отдельная таблица, и, похоже, на большинстве SSD она вообще упрощена до предела. Блок перестал стираться - его пометили "мертвый" и больше не используют. А всякими "для дальнейшей обработки" не заморачиваются.

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

Trim ничего не очищает. Эта технология переводит данные в состояние "мусор". А очисткой занимается сборщик мусора отдельно.

Отработка Trim - таки да: это команда очень объемная и "хранить ее до лучших времен" у контроллера просто негде. А сборка мусора - обычно идет в фоне и никому не мешает... Разве что прошивка "дохозяйствовалась" до того, что у нее закончился пул свободных для записи страниц: вот тогда все притормаживает сильнее - ведь кроме как записью, контроллеру приходится заниматься одновременно и сборкой мусора, чтобы расчистить блоки для продолжающейся записи.

да это я упростил

В принципе суть моего посыла , что проблема аппаратная и софтварно не лечиться (как минимум мной и сейчас), а дает временное облегчение.

А вообще дополнительные трансляторы в SSD и в SMR это дополнительные проблемы и тормоза.

[Allex]

ну да а кто тогда передет нам не полный обьем в ЛБА

Не понял... Р каком объеме речь?

я ж и писал что это он делает на основании контрольной сумы страницы

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

с замедление согласен а вот с тормозами , таки продолжаю считать что это деградация чипа или его не пропай

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

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

!Вычислить чип" - на самом деле не просто, а очень просто. Запускаешь Flash ID для соответствующего контроллера - и он тебе выдаст всю карту битых блоков. Только вот если SMART особых проблем не показывает, а SE помогает решить вопрос - то это определенно не аппаратная беда.

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

Ну вот я производителей, заморочившихся, пока не встречал.

В принципе суть моего посыла , что проблема аппаратная и софтварно не лечиться (как минимум мной и сейчас), а дает временное облегчение.

По моему опыту - замечательно лечится.

А вообще дополнительные трансляторы в SSD и в SMR это дополнительные проблемы и тормоза.

Только я бы не сваливал их в одну кучку - это принципиально разные трансляторы и работают они на совершенно разных принципах. Да и заточены под совершенно разные условия работы.

P.S. А вообще - о каком SSD речь? Что за контроллер, что за флеш?

[Datarecover]

Отнюдь. Я на своих SSD изначально оставляю порядка 10-15% пользовательского объема неразмеченными (это гарантирует постоянное наличие свободного пространства и меньшее усиление записи, и, соответственно, меньшую фрагментацию трансляторов в результате), и с такими трудностями пока не встречался ни разу. И те мои знакомые, которые на эти грабли уже наступили, но сделали так же как и я, а дополнительно - дали по рукам десятке (я ею вообще не пользуюсь) - тоже годами таких проблем не испытывают.

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

[Allex]

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

С чего бы?.. У нас большинство ставят свякие "сборки", у которых "расширенная диагностика" отключена по умолчанию, так что и проблем возникнуть просто не с чего.

и производитель будет менять софт для сдержания возвратов

Ото ему не хватало... ;+))

а не прикалываться с урезнием размера

Ой. Вообще-то Over-Provisioning - это штатная операция, рекомендуемая производителями для высоконагруженных SSD...

хотя возможно это и приведет к тому что у нас будут вытеснены проблемные блоки в созданный нами резерв.

У SSD не бывает "проблемных блоков". Есть блоки исправные, работающие в общем пуле, и есть неисправные, из эксплуатации выведенные. У исправных - есть некоторое колво параметров (точно - количество стираний, с большрй вероятностью - количество чтений, так как чтения тоже влияют на успешность чтения данных). Никаких упоминаний о "проблемных блоках" мне в литературе пока что не встречалось.

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

[Datarecover]

!Вычислить чип" - на самом деле не просто, а очень просто. Запускаешь Flash ID для соответствующего контроллера - и он тебе выдаст всю карту битых блоков.

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

P.S. А вообще - о каком SSD речь? Что за контроллер, что за флеш?

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

У SSD не бывает "проблемных блоков". Есть блоки исправные, работающие в общем пуле, и есть неисправные, из эксплуатации выведенные. У исправных - есть некоторое колво параметров (точно - количество стираний, с большрй вероятностью - количество чтений, так как чтения тоже влияют на успешность чтения данных). Никаких упоминаний о "проблемных блоках" мне в литературе пока что не встречалось.


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

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

[Allex]

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

Намного проще.

Вот тебе вывод phison_flash_id:

» Нажмите, чтобы показать спойлер - нажмите опять, чтобы скрыть... «

v0.33a
OS: 10.0 build 19042
Drive: 2(NVME)
Driver : W10(2:3)
Model : SPCC M.2 PCIe SSD
Fw : ECFM32.1
Size : 244198 MB [256.1 GB]
LBA Size: 512
Read_System_Info_5008 error: -1
Firmware lock supported [02 01] [P004] [0100]
Drive unlocked [02 03]
F/W : ECFM32.1 00
P/N : 511-210113202
Bank00: 0x9b,0xc3,0x48,0x25,0x10,0x0,0x0,0x0 - YMTC TLC 256Gb/CE 256Gb/die
Bank01: 0x9b,0xc3,0x48,0x25,0x10,0x0,0x0,0x0 - YMTC TLC 256Gb/CE 256Gb/die
Bank02: 0x9b,0xc3,0x48,0x25,0x10,0x0,0x0,0x0 - YMTC TLC 256Gb/CE 256Gb/die
Bank03: 0x9b,0xc3,0x48,0x25,0x10,0x0,0x0,0x0 - YMTC TLC 256Gb/CE 256Gb/die
Bank04: 0x9b,0xc3,0x48,0x25,0x10,0x0,0x0,0x0 - YMTC TLC 256Gb/CE 256Gb/die
Bank05: 0x9b,0xc3,0x48,0x25,0x10,0x0,0x0,0x0 - YMTC TLC 256Gb/CE 256Gb/die
Bank06: 0x9b,0xc3,0x48,0x25,0x10,0x0,0x0,0x0 - YMTC TLC 256Gb/CE 256Gb/die
Bank07: 0x9b,0xc3,0x48,0x25,0x10,0x0,0x0,0x0 - YMTC TLC 256Gb/CE 256Gb/die
Controller : PS5012-E12 [PS5012AA]
CPU Clk : 666
Flash CE : 8
Flash Channel : 8
Interleave : 1
Flash CE Mask : [++++++++ -------- -------- --------]
FlashR Clk,MT : 666
FlashW Clk,MT : 666
Block per CE : 2012
Page per Block: 1152
Bit Per Cell : 3(TLC)
DRAM Size,MB : 256
DRAM Clock,MHz: 1600
DRAM Type : DDR3
PMIC Type : PS6102/PS6106
PE Cycle Limit: 3000
ONFI : YMTC YMN08TE1W00C3B (2020-44) [DE12]
Page size : 18432 (16384+2048)
Page/Block: 1152
Block/LUN : 2012
LUN/Chip : 1
Bit/Cell : 3 (TLC)
Endurance : 3000
PlanAdrBit: 1 (2 plane)


Defects Early Read Prog Erase
Bank00: 7 0 0 0
Bank01: 7 0 0 0
Bank02: 4 0 0 0
Bank03: 6 0 0 0
Bank04: 16 0 0 0
Bank05: 16 0 0 0
Bank06: 6 0 0 0
Bank07: 6 0 0 0
Total : 68 0 0 0

Defects Early Read Prog Erase
Ce00Pl0: 3 0 0 0
Ce00Pl1: 4 0 0 0
Ce01Pl0: 3 0 0 0
Ce01Pl1: 4 0 0 0
Ce02Pl0: 2 0 0 0
Ce02Pl1: 2 0 0 0
Ce03Pl0: 4 0 0 0
Ce03Pl1: 2 0 0 0
Ce04Pl0: 10 0 0 0
Ce04Pl1: 6 0 0 0
Ce05Pl0: 13 0 0 0
Ce05Pl1: 3 0 0 0
Ce06Pl0: 4 0 0 0
Ce06Pl1: 2 0 0 0
Ce07Pl0: 3 0 0 0
Ce07Pl1: 3 0 0 0
Total : 68 0 0 0

Последние блоки - это как раз перечисление дефектных блоков.

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

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

Теперь - "долгое чтение". Оно бывает по двум причинам: утекший заряд в ячейках (дрянная память, или изношенная память, или долгое хранение при повышенной температуре, или активное чтение одного и того же места или комбинация перечисленного) - тогда флеш многократно читает страницу в надежде, что в какой-то из разов она прочитается так, что алгоритмы восстановления данных сумеют восстановить исходное ее содержимое, или - многократное обращение к всему массиву флеша с тем, чтобы найти нужную страницу ("безбуферный SSD", замученный транслятор). Что характерно - SE помогает при немедленной проверке чтения в обоих случаях: так как после SE читать из флеша ничего не нужно - то контроллер на запросы отплевывается нулями сразу же, с максимальной скоростью. Потому - чтобы понять, какой из этих двух вариантов имеет место быть, стоит после SE линейно прописать весь накопитель ненулевым паттерном (хотя бы тот же тест записи поверхности у AIDA), и дать ему полежать хоть несколько дней (если есть возможность положить в тепло - это будет еще надежнее). Если после такого выдерживания на графике чтения AIDA окажутся глубокие провалы (неглубокие - не в счет, они могут аозникнуть по массе причин, например, при переписывании данных из SLC буфера в постоянное хранилище) - то скорее всего дело в флеше. Если же график чтения получится более или менее ровным - дело было в трансляторе.

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

Не. В HDD LBA адреса жестко привязаны к физическим адресам секторов на пластинах, потому, когда какой-то сектор оказывается неисправным - нужен механизм замены вычисляемого по LBA физического адреса на подменный сектор. В SSD же данные, связанные с LBA, изначально могут быть где угодно и могут в любой момент времени быть перенесены в любое другое место. Потому "транслятор" в SSD - это не время от времени пополняемый "список замеченных опечаток", а постоянно меняющаяся "адресная книга", без которой на SSD вообще невозможно найти что бы то ни было.

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

Не встречал я пока такой стадии в SSD. Блок ушел на стирание, после стирания - проверка: стерся? - порядок, добавляем его в пул готовых к записи страниц, не стерся? - пробуем еще раз и опять проверяем, не получилось - объявляем мертвым. Проверка состояния всех бит блока после подачи на него стриающего импульса - это не "стадия принятия решения", а штатная часть процесса стирания.

По поводу параметров где они содержаться в заголвке страницы ?

А вот это - уж как в прошивке прописано. Страница, кстати, здесь ни при чем - это параметры блока стирания, а не отдельной страницы. А вот где их хранить - возможны варианты. Это может быть как отдельная таблица, так и использование какого-нибудь блока избыточных битов самого блока стирания... Первый вариант удобнее для организации поиска наиболее/наименее заезженных блоков, второй - для обеспечения надежности привязки счетчиков к конкретному блоку. Ну и комбинацией из обоих способов тоже вполне можно воспользоваться.... ;+))

[Datarecover]

Намного проще.

Вот тебе вывод phison_flash_id:

да спасибо. Просто те утилиты что попадальсь раньше, полезными для восстановления не были и я пеерстал им уделять внимание. Да и в основном в доступе были утилиты тоько для UFD. А для починки дисков приходилось разбирать фирмварь.

Теперь - "долгое чтение". Оно бывает по двум причинам: утекший заряд в ячейках (дрянная память, или изношенная память, или долгое хранение при повышенной температуре, или активное чтение одного и того же места или комбинация перечисленного) - тогда флеш многократно читает страницу в надежде, что в какой-то из разов она прочитается так, что алгоритмы восстановления данных сумеют восстановить исходное ее содержимое, или - многократное обращение к всему массиву флеша с тем, чтобы найти нужную страницу ("безбуферный SSD", замученный транслятор). Что характерно - SE помогает при немедленной проверке чтения в обоих случаях: так как после SE читать из флеша ничего не нужно - то контроллер на запросы отплевывается нулями сразу же, с максимальной скоростью. Потому - чтобы понять, какой из этих двух вариантов имеет место быть, стоит после SE линейно прописать весь накопитель ненулевым паттерном (хотя бы тот же тест записи поверхности у AIDA), и дать ему полежать хоть несколько дней (если есть возможность положить в тепло - это будет еще надежнее). Если после такого выдерживания на графике чтения AIDA окажутся глубокие провалы (неглубокие - не в счет, они могут возникнуть по массе причин, например, при переписывании данных из SLC буфера в постоянное хранилище) - то скорее всего дело в флеше. Если же график чтения получится более или менее ровным - дело было в трансляторе.

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

Не. В HDD LBA адреса жестко привязаны к физическим адресам секторов на пластинах, потому, когда какой-то сектор оказывается неисправным - нужен механизм замены вычисляемого по LBA физического адреса на подменный сектор. В SSD же данные, связанные с LBA, изначально могут быть где угодно и могут в любой момент времени быть перенесены в любое другое место. Потому "транслятор" в SSD - это не время от времени пополняемый "список замеченных опечаток", а постоянно меняющаяся "адресная книга", без которой на SSD вообще невозможно найти что бы то ни было.

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

Не встречал я пока такой стадии в SSD. Блок ушел на стирание, после стирания - проверка: стерся? - порядок, добавляем его в пул готовых к записи страниц, не стерся? - пробуем еще раз и опять проверяем, не получилось - объявляем мертвым. Проверка состояния всех бит блока после подачи на него стриающего импульса - это не "стадия принятия решения", а штатная часть процесса стирания.

ну так это и есть стадия заполнения Г листа , но она наступает для блоков которые ПОМЕЧЕНЫ для стирания, основной процес их не стирает а помечает. а пост процес стираетю На хдд это чуть иначе там основной процес осуществляет записи и\или чтение (для сигейта) и если сектор выщел за пределы по времени он уходит в пендинг лист и тем самым покинул зону трансляции , затем во время постпроцесса на него даеться несколько проверок и он помещаеться в Г-лист либо возвращается в резерв. ССД тоже используют основной поток работы и вторичный и основной поток не стирает данные а стираються они в доп потоке который я и назвала стадией принятия решений, ну пусть будет процесом стирания. Но в софте начинается гонка за ресурсами на уровне таблицы блоков помеченных для удаления , я понимаю что это можно расписать еще более подробно поключивши туда трим и шурфинг , но это работа штатная и она одинаково работает на одинаковой прошивке. Я иногда подбирал случайную запись при котрой эти тормоза становились заметны, хотя они уже проявляються на стадии выхода за пределы буфера, но не видел перманентного торможения (хотя наверно попробую создать такой тест) поэтому и относил это все к железу.

И еще, мне в основном уже доходят диски с явными проблемами, тк их уже часто смотрели ля меня , может по этому те что лечаться копированием просто не доходят.

[Allex]

В отличие от HDD, в котором свежие данные пишутся просто поверх прежних, в SSD данные пишутся только в чистые, предварительно стертые, страницы из пула готовых к записи страниц. И проверка результатов стирания - делается обязательно при каждом стирании. То есть - никаких "pending" блоков стирания у SSD не бывает. Не стерся с какой-то по счету попытки - на выход. И все.

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

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

[Datarecover]

В отличие от HDD, в котором свежие данные пишутся просто поверх прежних, в SSD данные пишутся только в чистые, предварительно стертые, страницы из пула готовых к записи страниц. И проверка результатов стирания - делается обязательно при каждом стирании. То есть - никаких "pending" блоков стирания у SSD не бывает. Не стерся с какой-то по счету попытки - на выход. И все.

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

я и писал , что в ССД нет пендингов. В них эту фукцию выполняет список помеченных на стирание. И поэтому они тоже могут быть подвержены своеобразному пендинг багу и именно его и лечат стиранием. Но я сейчас посмотрел базу и выяснил , что ни из затертых у меня не прожил дольше нескольких месяцев. Хотя часть их них уже не определялась при поступлении ко мне , и были починены софтово , обновление софта пересчет транслятора с сертификацией. А для тех что определялись просто SE.

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

Да и поэтому часто приходиться нагревать чип при вычитке , но в моем случае я проверил диск когда он уже остыл. И в отличие от софтово чиненных работает уже несколько лет в нотике.

я и писал , что в ССД нет пендингов. В них эту фукцию выполняет список помеченных на стирание. И поэтому они тоже могут быть подвержены своеобразному пенлинг багу и именно его и лечат стиранием. Но я сейчас посмотрел базу и выяснил , что ни из затертых у меня не прожил дольше нескольких месяцев. Хотя часть их них уже не определялась при посткплении ко мне , и были починены софтово , обновление софта пересчет транслятора с сертификацией. А для тех что определялись просто SE.
Да и поэтому часто приходиться нагревать чип при вычитке , но в моем случае я проверил диск когда он уже остыл. И в отличие от софтово чиненных работает уже несколько лет в нотике.

PS Но наличие достаточного количества утилит и методик тестирования, думаю позволят точнее определять с чем именно проблема.

Сообщение отредактировал Datarecover - Apr 23 2021, 14:01