Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Hardware » Магнитные носители информации » Ремонт накопителей WD (Western Digital). Часть VII

Модерирует : Akam1, Dr_StandBy, Dekker

Akam1 (30-06-2017 04:51): http://forum.ru-board.com/topic.cgi?forum=84&topic=5294  Версия для печати • ПодписатьсяДобавить в закладки
На первую страницук этому сообщениюк последнему сообщению

   

Rubicon2014

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
IAMLegenda
Моя эпопея походу закончилась.кто следил тот знает-вернее в курсе.Больше месяца прошло и удалось победить.  
восстановленный образ был битый поэтому надо было восстанавливать транслятор.  
Без Кикмана ваще ничего бы не было. сначала он мне С восстановил.Потом убил))  
Потом аж 8ч. чегото делал и вуаля-винда запустилась но без Д.  
Вебмани и т.д. заработало. потом опять хххх часов и диск Д появился!! Все расшифровал скопировал куда надо..Ща убираем бэды-делаем образ винды и чистим марвелом ди ск.Вроде так.  
Короче-если у вас проблемы- и нужна помощь,обращайтесь  к Кикману.  
Спс тебе большое!  
упд.БЕСПЛАТНО-парень ничего не просил,в отличии от некоторых  
упд.не реклама,просто спс и восхищение
Kickman
Я дополню. Транслятор восстанавливал на основе P-list, восстановленного из лога селф-скана. Нашлось всего 2 сдвига на весь диск, оба в системном разделе. +несколько областей с BAD~ами. +конец диска вообще обнулён, а как раз там и лежал архив системного раздела, конкретно файл ".002". Он и погиб, этот .002. Не удалось найти его начало никак. Что-то с транслятором конца диска случилось . Ну да ладно, автору проблемы этот конец и не нужен оказался.  
Первый сдвиг, 250 секторов, попал внутрь файла System.ServiceModel.dll - файл оказался не критичным, лежал в winsxs.  
Второй сдвиг попал на program files\freetime\formatfactory\ffmodules\encoder\codecs\quicktime.qts - файл тоже убит, но не критичен.  
Сдвиги вычислял с помощью DMDE и инструмента "Карта кластеров". Было бы удобнее, если бы иметь возможность искать секторы, содержащие все нули, или наоборот, такие, где НЕ ВСЕ НУЛИ. Искал по заголовкам файлов. EXE, DLL, AVI, PNG и т.п., начала которых легко распознавать.  
Оба сдвига оказались в районах с BAD-секторами. Поступал так: очистил списки G+Relo, P. Восстановил P из лога селф-скана. Пересчёт транслятора с учётом P. Снова очистил G+Relo, чтобы избежать Pending~ов и прочей мути. Диск начал удовлетворительно работать в DMDE, отобразил первый раздел. Второй поискал поиском загрузочного сектора, нашёл сдвиг в 274 сектора. Стал искать сдвиг по заголовкам файлов раздела с помощью карты кластеров, от половины, потом снова делил пополам, и так далее. Когда нашёл, на каком файле сдвиг, то с помощью WDmarvel сделал "Добавить дефект в G-list по LBA" - увидел его адрес в G-list в виде дорожки, головки, сектора. Дальше - внёс нужный диапазон секторов от этого адреса в P-list, пересчитал транслятор с учётом P-list. Всё. Сдвиги пропали. Данные на месте. Винда запустилась. Потом долго проверял второй раздел, там сдвигов НЕТ!!! Но конец обнулён, данных не видно, около 2 Гб, наверное. Точно не помню уже. Чекдиск, вроде, даже не ругался на разделы. Или чуть-чуть на системный. То есть, все служебные структуры уцелели.  
Потом, для первоначального оживления, чтобы без BAD~ов прочитать системный раздел, выполнил в Виктории в режиме PIO: Verify+REMAP. В режиме API - не работал REMAP! По номерам REMAP~нутых секторов (оказались софт-бэды) в DMDE проверял в карте кластеров принадлежность этих "битых" секторов файлам. Критичных файлов на системном разделе не пострадало. Можно архивировать системный раздел на другой носитель, диск довести до ума в WDmarvel, накатить из сохранённого архива систему на освежённый диск и радоваться . Возможно, даже второй раздел не пострадает при ремонте .  
 
Добавлено:  
Ещё была трудность в том, что сначала не хотели дефекты добавляться по LBA. И транслятор пересчитывался больше 3 минут без видимых признаков работы. Минут за 5 в итоге стал пересчитываться. Всё это выяснил и устранил, когда несколько часов провёл, ковыряясь в служебке и её разных копиях, очищая модули и комбинируя их... это была подготовка. А потом дня 3 работы... По первости. Теперь-то опыт появился кое-какой. Увлекательное было мероприятие .  
 
Добавлено:  
Можно назвать "Восстановление транслятора по-живому" на диске с данными.
n_so

Цитата:
Дальше - внёс нужный диапазон секторов от этого адреса в P-list

 
Равный сдвигу? По вашему тексту - 274.  
А как вы точный адрес нашли? Или удовлетворились произвольным в пределах битого файла?  
Kickman
Именно так. Посмотрел, где в битом файле начинаются нули, и этот сектор внёс как дефект по LBA в G-list. И адрес +250 для первого сдвига или +24 для второго сдвига. Повезло, что сдвиги вместились в одну дорожку по одной головке, иначе пришлось бы повозиться чуть дольше. Самое длительное было - это подготовка служебки (чистка списков дефектов и пересчёт транслятора) и поиск мест сдвигов.  
Однако, нулей там было явно больше, чем сдвинутых секторов. Но файлы не критичные, вот список:  
Кластер 5464790 в начале смещение 0 System.ServiceModel.dll – а в конце смещён. Будет битый.  
43925907 – пошли нули в секторах  
43937122-43936872=250  
Кластер 5846885 секторы 46982178-1928=250  
Смещён между ними файл codecs \ quicktime.qts – он будет битый.  
Кластер 5847995 46991082-990808=274  
Ну, и ещё по поводу БЭДов (сканил Викторией перед работой в WDmarvel):  
Нули в секторах 9375888-9375903, из них #9375893=BAD – REMAP, файлов нет  
14211072 Error: ABRT prog_f\Intel\IRST\es-ES\IaStorHelp.Resources.dll  
Driverstore\filerepository\cw122944.inf_x86_neutral_4cb34b2046e37038\B123158\atieclxx.exe  
15028224 Error: ABRT не подтвердились или перезаписаны  
15157248 Error: ABRT не подтвердились или перезаписаны  
15204352 Error: ABRT не подтвердились или перезаписаны  
15237120 Error: ABRT не подтвердились или перезаписаны  
43925504 Error: ABRT windows\winsxs\...\System.ServiceModel.dll  
46987264 program files\freetime\formatfactory\ffmodules\encoder\codecs\quicktime.qts  
48867328 Error: ABRT windows\winsxs\...\ntkrnlpa.exe  
75917312 Error: ABRT windows\Installer\13ecaac2.msp  
90075136 Error: ABRT 90076016 - пусто  
90814464 Error: ABRT пусто  
96264192 Error: ABRT ничего существенного  
96327680 Error: ABRT ничего существенного
szlodey
Можно немного подробнее как вы искали "сдвиг", как вообще понять что это оно?
Kickman
в DMDE открываем файловую систему тома(раздела), берём карту кластеров, смотрим файл с характерным началом из последних кластеров на разделе (в районе 7 млн или 8 млн для 64Гб-ного раздела). Например, EXE/DLL начинается с "MZ". А мы видим там в соответствующем секторе чушь. Запускаем "поиск": сектор, содержащий "MZ" в позиции 0 от начала, вперёд. Находит невдалеке. Считаем разницу секторов, у меня получилось 274. Сокращаем наполовину, смотрим в районе кластера № 3-4 млн. В итоге, находим конкретное место, где данные на месте - а сразу в следующем файле уже не на месте. Между ними могут быть (на месте сдвига) нули или BADы. Затем эти секторы диска (строго по сдвигу) исключаем из транслятора. Если "нулёвых" или "BAD"овых секторов было больше, чем исключили, то файл пострадал (у меня получилось именно так, благо, файлы были не критичные). Как-то так. Это надо пробовать. Если есть подопытный, могу показать на нём. Учтите, это долго.  
 
Добавлено:  
Дополню, как я решился на это дело:  
Ссылка
Ссылка
szlodey
Спасибо доступно объяснили. Если у нас разрыв попадет между известными файлами на большой кусок неиспользованного пространства, то как я думаю нужно с битого файла (который следующий за нормальным) посекторно читать назад и как только нарвемся на первый бэд - это и должен быть софтбэд вызванный разъездом и с этого адреса и вносим в плист? Хотя если битый файл некритичен как я понял вы заносили прямо с него?  
Kickman
 Куча вопросов...  
Попробую ответить пошагово.  
Задача стояла восстановить транслятор, чтобы восстановить данные. Поэтому я не очень-то обращал внимание на содержимое секторов и BADы.  
Получилось так, что начало файла на месте, а конец сдвинут вперёд на 250 секторов. Поэтому я стал искать в пострадавшем файле сектор, заполненный нулями - и внёс его как первый исключаемый. Пролистал файл вперёд - в секторах нули или BADы. До конца файла было далеко, я добавил 249 к номеру первого внесённого сектора, внёс сектор с полученным номером как последний исключаемый. Итого исключив 250 секторов. В списке G-list (изначально пустом) стало видно, что эти дефекты находились на одной дорожке&головке. Я внёс эту группу секторов ОТ первого и ДО последнего в P-list, и удалил 2 дефекта из G-list, перезапуск F/W, запустил пересчёт транслятора с учётом P-list. Сдвиг убрался. Однако, в пострадавшем файле было "нулёвых" секторов больше, чем я исключил, так что файл погиб. Но он не нужен.  
Второй сдвиг был на 24 сектора, а ситуация полностью аналогична. Файл тоже пострадал. Начало на месте, конец съехал, в середине нули и BADы. После исключения - нули и BADы остались, хотя и в меньшем количестве, чем ДО исключения.  
Поскольку диапазон секторов исключался скорее по принципу "от балды", чем по принципу выбора реально битых секторов, то на диске со временем могут вылезти BADы. Перезапись их вылечила, но надолго ли (?)...  
Реверсом читать не пробовал, ибо без нужды. Задачи восстановить ВСЁ не стояло, а ко всему нужному доступ получен
 

Всего записей: 640 | Зарегистр. 21-04-2016 | Отправлено: 21:07 07-04-2017 | Исправлено: Rubicon2014, 22:40 13-04-2017
   

На первую страницук этому сообщениюк последнему сообщению

Компьютерный форум Ru.Board » Hardware » Магнитные носители информации » Ремонт накопителей WD (Western Digital). Часть VII
Akam1 (30-06-2017 04:51): http://forum.ru-board.com/topic.cgi?forum=84&topic=5294


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.Board
© Ru.Board 2000-2020

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru