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

[rapid]

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

вы ж понимаете, что на слух все очень субъективно...
вот ТУТ можно послушать, что и как звучит на самом деле....

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

про такого родо случаи более подробно можно прочитать тут:
http://www.chip-center.dn.ua/vosstanovleni...acii-v-donetske
читать, начиная со слов "Многие пользователи пытаются сами пробовать восстановить потерянную информацию."

Мини FAQ по HDD


===
В общем винт периодически на несколько секунд перестает работать типо щелчок и останавливается но сразу же запускается при этом виндовс зависает и приходится перезагружаться(( Вот сижу и думаю что делать брать новый или можно что то сделать с этим)

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

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

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