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

[Hose]

Добрый вечер всем.я тут новенький,хотел бы у вас узнать есть ли какая то программа что может помочь мне в моей проблеме *???Я проверил программой свой винчестер Viktoria у меня нашел 217 оранжевых сектором а так же температура моего винчестера 48 градусов и еще,проверил другой программой "Hard Disk Sentinel"
тоже самое показало за температуру и написала вот такую ошибку..

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

Можно как то это решить вообще???эту проблему??

[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. Блок ушел на стирание, после стирания - проверка: стерся? - порядок, добавляем его в пул готовых к записи страниц, не стерся? - пробуем еще раз и опять проверяем, не получилось - объявляем мертвым. Проверка состояния всех бит блока после подачи на него стриающего импульса - это не "стадия принятия решения", а штатная часть процесса стирания.

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

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