» Ремонт накопителей WD (Western Digital). Часть IV

south_man
Ок, буду иметь ввиду на будущее.
Тута плата 1640 но ревизии несколько разные, + та что поставил - немного "упрощенная" (отсутствует часть элементов типа датчиков вибрации)...

NiTr0

Цитата:

отсутствует часть элементов типа датчиков вибрации

та это ладно - вы внимательно просмотрите дороги к гермоблоку... там бывает и резюки в разных положениях и сами дороги ходят то налево то направо
про 1640 так сходу не скажу.. может тогда еще "все проще было" на кухне ВД..

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

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

Эх, запаяю новую флэш, зашью туда ром, выдеру из рома модули и перепишу насильно, потом - сделаю дамп и посмотрю что поменялось...

Цитата:

Всё же WDBlack - далеко не ширпотреб. Дадут вам взамен какой-то "грин" и привет

С чего бы это?
Отсылал неоднократно по RMA харды и всегда замена производилась корректно.
Т.е отправил Black-получил в замен Black,отправил Green-в замен тоже Green.
Red тоже меняют на Red
Когда нет нужного объёма то они присылают ближайшего объёма в большую сторону.Цвет всегда соблюдают.
Отправлял недавно партию среди которых был 750 Black-в замен получил 1 TB Black


Цитата:

Для диагностики/замены лучше обращаться через гарантийку фирмы-продавца (где был куплен винт) или лучше напрямую отсылать винт почтой в московской представительство WD ?

Если гарантия от магазина где вы брали ещё не закончилась-то несите в магазин,а точнее в сервис центр этого магазина.
Если гарантия от магазина закончилась,но на сайте WD гарантия ещё действует-тогда создавайте RMA и отправляйте WD
Не надо никаких отчётов(лично я никогда не прикладывал)при создании RMA там можно выбрать что за проблема с диском.Выбирайте не определяется.

Доброго дня.
Чайниковский вопрос, но сейчас нет пустого WD винта для опытов.

Подскажите, в в WD Marvel какие опции деструктивны для информации.
Образовался еще один WD GREEN, теперь уже на 2 тб, тож окислились контакты к БМГ и он успел в СМАРТ напридумывать о себе плохого.
Контакты почистил, хотелось бы ему и мозги вправить.

Информация меж тем на диске жива.
Если в WD Marvel DEMO ткнуть "очистить SMART", инфа слетит?

Предполагаю, что очистка RELO-LIST и G-LIST - деструктивна, это так?

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

Цитата:

Если в WD Marvel DEMO ткнуть "очистить  SMART", инфа слетит?
 
Предполагаю, что очистка RELO-LIST и G-LIST  - деструктивна, это так?

от очистки СМАРТа инфа не слетит, но и пункт по переназначенным секторам может не сбросится в 0. Для этого как раз второй пункт нужен.
После очистки рело и Г, на ВД, я не помню, чтоб слетал транслятор - просто у вас повылазят на поляну те сектора, которые были ранее не читаемы. И без перезаписи которых, диск скорее всего, затолкает их обратно в Г и рело при след. чтении.

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

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

Цитата:

г/рело чистить командой - они винтом вроде стираются.

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


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

Я бы списки оставил как есть и ограничился сбросом СМАРТа.. если этого не хватает, то тогда уже пройтись по спискам с принудительной очисткой всех данных - так будет надежнее на будущее.

Цитата:

если были переназначены сектора, то инфа в них уже была утрачена

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

Цитата:

в них лезет с переносом инфы в резервный

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

или я что-то не то говорю?

tomset
мерси за пояснения и освещения этих моментов!
сразу вопрос - "сомнительные сектора" при очистке рело вылезут на поверхность, так? Т.е. транслятор их "включит" и в ЛБА теперь на месте годных будут те, что были скрыты?

вот были данные в секторах лба 10 11 12 13.., пускай 11 - это замещенный сектор из резерва с "достоверным содержанием".
мы чистим рело, на место 11 лба вылазит этот проблемный... теперь у нас ситуация: 10 11* 12 13 .
В 11* будет попытка записать содержимое 11?
и если запись=ОК, то данные сохраняются, если нет, то 11* снова попадет в рело, а остается на месте все тот же 11?

ну и тут ньюанс, что рело-лист отдельно чистить позьзователям ВДмарвел вроде не дано..

Mihatut
если отбросить тот сумбур, который я написал постами выше, то вот резюме, абсолютно точно отвечающее вашему вопросу:

Цитата:

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

Цитата:

"сомнительные сектора" при очистке рело вылезут на поверхность, так?

А они с нее никуда и не девались. Потому как рело лист - это список кандидатов на помещение в реаллокейты.

К слову, при чистке г-листа командой - чем переписывается сектор? Нулями, или данными которые содержались в резервном секторе, его заменяющем?

tomset
ага. понял. спасибо! Модуль убить действительно просто.. теперь ясно, что на трансляцию в общем-то, это не повлияет.
Slow-responding - это следствие этой же проблемы, когда рело оч.большойи его обработка занимает бОльшую часть времени?
или есть еще причины, которые приводят к аналогичным тормозам и отказу реагировать на внешний мир?

Но более правильный вопрос задал NiTr0 чуть выше про Г-лист)

Цитата:

при чистке г-листа командой - чем переписывается сектор?

Кем переписывается ?

Цитата:

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

Я о команде чистки г+рело.

Цитата:

Потеряется список сбойных и проблемных секторов.
Сами сектора ни как не затронутся.

Тогда почему винт при подаче этой команды что-то делает с секторами (судя по статусу), причем - довольно длительное время, причем - порой вываливаясь с ошибкой?

Натолкайте в глист или рело-лист секторов вручную, и дайте команду очистки листов. Посмотрите поведение.

tomset
Я не о том. Я о том, что команда чистки листов выполяется не мгновенно - идет некоторое время, в процессе которого что-то делает с секторами в UA. И может завершиться ошибкой, если чистятся листы на винте с реальными бэдами.

Цитата:

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

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

Продолжение.
Весело.
Очистил СМАРТ и relo+G list, на диске дематерилозовалась partition table.
Не, testdisk ее находит, да и r-studio папки видит, т.е. доступ к юзерзоне не потерян, но операция оказалась вполне себе деструктивной.
Обидно.
Главное, то что в смарте ремапов то не было, была лишь куча pending sector.

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

Цитата:

Очистил СМАРТ и relo+G list, на диске дематерилозовалась partition table.

Mihatut
ну так вам же советовали

Цитата:

Я бы списки оставил как есть и ограничился сбросом СМАРТа..

и тут говорили:

Цитата:

Поэтому при очистке G-листа, если в резервный сектор, уже были новые записи, возможно восстановление древней неактуальной информации,

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

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

Цитата:

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

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

NiTr0

Цитата:

вполне вероятно, сектора из рело записью проверяет на предмет софт-бэд или нет

очень может быть, да, но я внесу еще немного сумбура - замечал что команда "очистки G и Relo" по-разному отрабатывает в зависимости или от семейства или даже от вари..
т.е.
1) да, иногда идет обработка, схожая на внутренний формат - я не копал, что происходит, т.к. эксперименты на данных не ставлю таким образом.
2) после команды сразу идет ресет вари (автоматом), как результат - списки чистые.
Что и какой пересчет был задействован для трансляции - не ясно, но поляна чтению поддавалась (но 100% или нет - не скажу, не проверял).
Я обычно след.шагом делаю пересчет с учетом Р, ну и прогон запись-чтение, чтоб понять как дела с поверхностью.

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

Цитата:

после команды сразу идет ресет вари (автоматом), как результат - списки чистые.

Такое есть, когда листы пусты, либо в них очень мало дефектов (ну не знаю сколько именно, может 10-20, очень мало ). В остальных случаях (я конечно не все семейства в руках держал, но на тех, что видел) если в листе скажем сотня дефектов ну или тем более, если больше - в общем-то всегда появляется то самое окошко статуса, где, как правильно замечено, бегают сектора, что-то с ними делается/ Скоре всего - проверка на читаемость, ибо были случаи, когда диск с полумёртвой головой нахватает в листы кучу бэдов и кандидатов, потом очистка такого листа может идти очень долго, минут 10 - 15, и вообще может зависнуть тупо на каком-то секторе...

кстати, Mihatut

Цитата:

Главное, то что в смарте ремапов то не было, была лишь куча pending sector.

в СМАРТе не всегда ремапы-то видны... штук 20-30-50 бывает, что в списках Глиста есть, а в СМАРТе по нулям.. уже говорили, что счетчик не всегда начинает счет с первого ремапа. Так что в списки смотреть, перед очисткой очень полезно

igor_me
интересное предположение, но у меня был случай когда под завязку забиты пункты по реаллокам и пендингам, делаю очистку 1) СМАРТ и 2) Г+рело - и тут же клац-клац, диск ребутнулся без всяких телодвижений Вроде на 2.5" такое чаще.. но на 3.5" точно было.. точно не скажу, увы.. нужно будет посмотреть.

2ALL
может кому из новичков полезна будет публикация:
материал описывает точки для подпайки к нативному порту сата на 2.5" юсб3.0 диске: My Passport Essential SE USB3.0
2060-771737-000 REV A

что меня порадовало, что автору удалось получить доступ к данным, т.е. диск без шифрования, что большая удача. Могло быть во много раз хуже, т.к. имея ситуацию "BAD PCB USB Device" пришлось бы менять целиком контроллер и пересаживать ПЗУ (U8 - традиционное, как я вижу, и U12 - прошивка моста юсб3.0)

Цитата:

Цитата:
Я бы списки оставил как есть и ограничился сбросом СМАРТа..  

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

Решил рискнуть сбросом листов...

Добавлено:

Цитата:

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

О!
Идея!
Тестдиск находит таблицу по странному смещению, норма+1 сектор, в норме тестдиск предлагает окончание ххх200, а по факту - 201.
Видимо она уехала, надо будет попробовать ее забекапить, а потом сунуть на правильное место.

Добавлено:

Цитата:

2ALL
может кому из новичков полезна будет публикация:
материал описывает точки для подпайки к нативному порту сата на 2.5" юсб3.0 диске: My Passport Essential SE USB3.0
2060-771737-000 REV A

Очень интересно!
Примерно такой USB диск на полтера подарили на опыты с месяц назад. Окисленные контакты БМГ, помойка в SMART и после очистки полная кома со стороны USB. Предполагаю, что если к нему подцепится через SATA - мозги вправить получится.

Mihatut

Цитата:

Раньше был HDDscan, но после трагедии с Радченко - ...Решил рискнуть сбросом листов...  

риск благородное дело, конечно, но не в случае с данными..
про трагедию, увы или к счастью, не слышал


Цитата:

Идея!

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


Цитата:

если к нему подцепится через SATA - мозги вправить получится

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

Цитата:

но после трагедии с Радченко

Это чё за трагедия такая и как она связана с записью дисков?????

что за DEBUGSTOP_OS_STACK_OVERFLOW и как с ней бороться

Переполнен стек? А это в каком контексте вообще, винда отваливается с синим экраном или как?

Цитата:

но после трагедии с Радченко
Это чё за трагедия такая и как она связана с записью дисков?????

Давно, в конце девяностых еще в FIDO был такой дядька, который писал утилиту hddscan, потом он внезапно умер.
В утилите был интересный режим тестирования, аналогов сходу не попадалось - недеструктивный тест записи.
Т.е. после кучи предупреждений, что эта самая недеструктивность может оказаться вполне деструктивной, тест начинал посекторно читать в память, а потом обратно записывать считанное на поверхность. Аналогичного функционала мне как-то больше не попадалось.
Предполагаю. что винт с почищенными контактами и прогнанный таким тестом вполне себе убрал бы pending sector из SMART.

Ну. а винт только что я поднял и даже с информацией. testdisk отыскал партицию, а FSCK восстановил структуру. Для пробы несколько торрентов заставил "пересчитать хеш" ошибок нет.
Ура!
Сегодня ребенка будет с мультиками.