Дали на ремонт комп... Сдуру включил в BIOSе SMART, после чего винт Maxtor Fireball 3 стал определяться как ARES C64K. Данные винта:
Maxtor Fireball 3
2F030J0310211
VAM51JJ0
KMCA
A8FFA (над IDE-разъемом)
Посторонних звуков нет, только двигатель шумноват (звенит).
Нужна инфа с винта (архив фоток хозяев этого компа). Ремонтника нашел (hdd-911.com), но пока есть надежда, что сделаю сам. Понимаю, что надежнее отдать в ремонт, но пока ищу инфу по форумам, на винт ничего не пишу...
PC3000 v.14, pcmx_pkr v.2.01 (более свежей не нашел, кстати, может кто поделится??)
Проверка служебки:
# PN UBA Size Rd ChkSum Id Comment
--------------------------------------------------------------------------------
20 18 0029 0004 - - - AT_PDL - P-List
25 1D 02A0 0002 - - - DMCS - таблица кэширования
35 30 018B 0001 - - - SMART Attributes - атрибуты SMART
41 41 018D 0002 - - -
45 45 018F 000C - - -
68 63 018C 0001 - - - Копия SMART атрибутов
77 70 0356 0001 - - - SMART Summary Log
Соотв. этим модулям файлы имеют расширение .BAD. В группах модулей соотв. места заполнены строкой "BAD!", причем в обоих копиях (в DMCS - оба сектора, в AT_PDL - первые 4 сектора BAD, потом нули). Вычитывание с игнорированием ошибок ничего не дает.
Еще есть модули (кроме этого списка), у которых не в порядке только CRC.
Оверлеи в порядке. Дефектов в служебке нет. Тест записи в служебку проходит (смещение: 0). Ресурсы с винта предварительно слил.
Почитав форумы и доки, пришел к выводу, что нужно восстановить только AT_PDL и может быть DMCS. Определил следующую последовательность действий:
1. Запускаем DOS.
2. Подаем питание на винт (перемычка установлена в safemode).
3. Запускаем эмулятор, затем pcmx_pkr.exe.
4. Загружаем лоадер (в режиме ПЗУ+модули).
5. "Стандартный режим".
6. Прописываем модули AT_PDL и DMCS от другого винта.
7. Выходим из программы, выключаемся, запускаем все заново (пп. 1-5).
8. Запускаем пересчет транслятора. Модули транслятора (в т. ч. AT_PDL) будут пересобраны из 33-го модуля (он в порядке).
Вопрос 1. Это правильная последовательность действий? Может чего-то не хватает, или наоборот лишнее? Данные на винте останутся?
Вопрос 2. Могу ли я использовать текущий лоадер (ес-но, это лоадер от другого винта)? Или прохождение теста записи служебки однозначно показывает, что лоадер подходит?
Вопрос 3. Меня смущает, что PC3000 выдает, похоже, не полную информацию о винте.
Верхняя строка. MODEL: MaxtorARES C64K VAM51JJ0 CYL:-1 HEAD:1 SEC:0
Нижняя строка. STATE: DONE: LBA: ERRS: (все пусто)
В строке флагов "красных" битов нет.
Это нормально?
P.S. Вчера угробил свой старый Calypso 6Y080L0, на котором экспериментировал. Кушает некоторые лоадеры, но в них (в тех, что пробовал) не идет тест служебки, проверка служебки показывает нечитаемость большинства модулей, а также ПЗУ и оверлеев. Ресурсы с него все есть, но свой лоадер тоже почему-то не кушает... Ес-но, инфы на нем ценной нет, но теперь вдвойне аккуратен, выверяю каждый шаг.
После самостоятельных попыток на кривой досовской PC3000,а к тому же ещё и ломанной цена за восстановление может в разы увеличиться.
А Ares настоятельно рекомендую сменить.отжили они своё(это переходная модель с новыми не отработанными до конца изобретениями инженеров-разработчиков компании Maxtor)
Если AT-PDL (P-List - таблица скрытых дефектов) не читается, то поверхность с денными правильно не считается из-за логического смещения секторов. Один скрытый в P-List дефект даёт пропуск сектора в логическом чтении. Если P-List не считался - все скрытые сектора восстановятся и дадут лишние сектора в логическом чтении. Получается так называемое смещение. У макстора таких скрытых секторов может быть до нескольких десятков тысяч. И смещение в таком случае получится очень большое, что приводит к невозможности правильного чтения по логике.
Тем более нельзя записывать P-List от другого (и тем более пересчитывать транслятор), сектора скроются совсем другие и данные разрушатся совсем. Особенно, если на диск произойдет запись, на что винда горазда уже при загрузке совершенно не предупреждая юзера.
В общем и целом - если даже и восстановишь запуск винта с чужим p-list, то данным придёт .... .
И ещё. У макстора p-list разбит на блоки и количество этих блоков прописывается в U-List е, что приводит к трудностям правильной заливки p-lista взад, даже если он и родной, если это количество разбежится.
Обороты могут временно срываться из-за изношенных подшипников, тогда макстор наделает сектров в G-Liste и опять может не считаться всё правильно.
Да, знаю, что они кривоватые, форумов начитался уже :) Винт не мой, но после восстановления надо будет его положить на полочку - у него в P-list'е 487 дефектов, в G-List'е 34. У моего Calypso, например, в G-list't было всего 5 дефектов.
Alexander_G, спасибо.
Про смещение секторов в случае скрытия через P-list (и про замещение, если через G-list) в курсе - читал документацию. Для восстановления инфы дефекты в P-list'е критичны, в G-list'е - не очень.
А как же тогда это (из документации к PC3000)?
Но вернемся к Maxtor. Данные программы транслятора находятся в следующих модулях: U_LIST (PN=37h), AT_PDL (PN=18h) и RZTBL (PN=78h). Накопитель формирует транслятор через промежуточную таблицу, имеющую PN=33h. В этой таблице дефекты указаны в их обычном представлении: цилиндр, головка, сектор. Существует возможность собрать таблицы транслятора из этой промежуточной таблицы при помощи команды “Пересчет транслятора” ...
Еще:
Задача восстановления транслятора возникает в случае, когда таблицы транслятора содержат неверные данные или не читающиеся сектора.
В такой ситуации возможно формирование таблиц транслятора на основе сводной таблицы дефектов (модуль PN=33h) при условии, что она не повреждена.
Чтобы запустить пересчет транслятора, необходимо выполнить команду “Пересчет транслятора” ...
Это да, винда сразу полезет корзины всякие создавать, лучше ее не подпускать к винту до снятия инфы. Буду линуксом копировать, если что.
А вот про это, если можно, поподробнее. По идее, если P-list родной, то кол-во блоков будет соответствовать кол-ву блоков в U-List'е. Кроме того, судя по документации (см. выше), U-list также будет пересобран в ходе пересчета транслятора.
Ну тут уж как повезет... Но если даже он эти новые дефекты не зафиксирует в G-List'e, но для восстановления инфы это по идее не настолько критично - опять из документации:
Скрытие дефектов в таблицу G-List осуществляется другим методом. Таблица G-List не производит исключения секторов из набора LBA. Она производит их замещение за счет резерва. Резерв находится за самым старшим LBA накопителя. ... При этом при скрытии дефектов в G-List смещения секторов LBA не происходит. Потеря информации в таблице G-List никак не сказывается на восстановлении данных. Конечно, возможно возникновение такой ситуации, когда скрытый накопителем в G-List сектор мог содержать критичную для функционирования файловой системы информацию. Но возникновение такой ситуации маловероятно и рекомендуется очищать G- List, если в нем были скрыты дефекты, в процессе восстановления поврежденной служебной зоны накопителя для снятия информации.
P.S. Все вышесказанное - только мои предположения, потому что я в этой области теоретик, а не практик. В общем, кто-то из нас двоих прав, моя задача - понять, кто :)
Делал такую штуку. Нормально получилось и данные восстановились. Но это если p-List целый и родной.
А насчёт G-List...
Тут как попадёт. Если посреди файла с фильмом или рисунком, то ерунда конечно-же. А если попадёт посреди FATа(для FATxx файловой системы) или на mft для ntfs, или на master boot record какого нибудь раздела? Тогда попрыгаешь, чтобы всё восстановилось.
FAT - 2 копии (хотя возможно придется ручками править). mft - как практика показывает, несколько дефектных секторов в ней не критичны для данных. MBR - вообще один, бут сектора - восстанавливаются.
Что вы имели в виду под "p-List"? Модуль AT_PDL, или 33-й модуль (HUTIL & HUSR, сводная таблица дефектов)?
Итак, есть модули AT_PDL, U_LIST и RZTBL. Есть 33-й модуль с той же инфой, только в другом представлении. Есть процедура пересчета транслятора, которая заново собирает AT_PDL, U_LIST и RZTBL (и, может быть, что-то еще) из 33-го модуля. 33-й модуль у меня в порядке. По идее, не должно влиять, в каком состоянии сейчас AT_PDL, ведь он будет записываться, а не читаться?
А G-list, как я понял из документации, вообще не причем к транслятору. Т.е. после пересчета должны получить тот же AT_PDL, что и раньше, а AT_POL (G-list) не меняется. По идее, все данные должны остаться на своих местах?
Я прав? Или я что-то упускаю?
Под p-list-ом имеется в ввиду 33-й модуль. Лежит внутри группы модулей Defect log( Чтение групп модулей -> группа Defect log).
Судя по тому что
должно получиться. Была у меня такая практика. Правда в единственном случае.
G-List тут ни при чём. Я просто привёл случаи которые у меня реально были при восстановлении данных. Конечно не так катастрофично, как с не читающимся p-list-ом, но приходится дополнительно "попрыгать".
Да. Именно это и имелось в виду. Т. е. дополнительные телодвижения в таких случаях.
Или вот ещё реальный случай.
У самсунга было переполнение по переназначенным секторам. Смарт стоял "BAD". Обнулил r-list (у самсунга). После этого данные побились, а там оказалось море образов дисков всяких разных games-ов, и все (!) образы оказались побитыми. Так и не пришлось на халяву ни в какую game поиграть.
Хотя... Бывет и g-list не даёт винту проинициализироваться. Из-за сбоя может быть неправильный сектор переназначения. В смысле - сектор переназначения записался криво и теперь указывает на сектор, который лежит вообще вне пределов допустимого дискового пространства. Здесь g-list надо обнулять.
И данные на винте остались после пересчета транслятора?
Отлично, раз вы это делали на практике, тогда задам вам более практические вопросы :)
1. Нужно ли перед пересчетом транслятора что-нибудь делать с нечитаемыми модулями:
AT_PDL
DMCS
SMART Attributes
Копия SMART атрибутов
SMART Summary Log
еще 2 неизвестных модуля 41 и 45?
Т.е. прописывать нули, прописывать модули от другого винта? Очищать P-list & G-list (только P-list вроде не получится, потом я верну обратно родной G-list)?
2. Как узнать, подойдет ли мне тот лоадер, который я использую сейчас? Структуру лоадера к сожалению не нашел, но, насколько я понял из форумов, там могут быть расположены модули критичности А (уникальные для винта). Может, я ошибаюсь...
Тест записи в служебку с этим лоадером проходит (смещение: 0).
3. Винт будет в режиме safemode, затем буду загружать лоадер в режиме ПЗУ+модули, потом Стандартный режим, ну и потом выполнять нужные действия. После каждой операции дергаем питанием винта (а лучше всего компа) и проверяем правильность выполнения. Это правильный порядок действий?
Может вы помните, какой был у вас порядок действий? И какие именно неисправности были у того винта?
Какая версия pcmx_pkr.exe у вас была (если конечно вы использовали DOS-версию)? У меня 2.01
4. Я не уверен, что PC3000 показывает правильную информацию о винте.
Верхняя строка. MODEL: MaxtorARES C64K VAM51JJ0 CYL:-1 HEAD:1 SEC:
Нижняя строка. STATE: DONE: LBA: ERRS: (все пусто)
Так и должно быть?
Заранее спасибо.
Остались. Повезло, наверное.
Записать от другого, раз уж родные не читаются.
Перед этим надо загрузить лоадер. Из под него создать родной лоадер, выкл-вкл и загрузить его. Все операции надо делать из под родного.
Проверить запись в СЗ. Сохранить память на всякий пожарный случай. Проверить, может нечитаемые модули стали читаться (вряд ли, но может чудо какое случится). Залить модули от другого макстора и пересчитать транслятор. Выкл-вкл уже в нормальном режиме. Авось заработает.
Операция пересчёта транслятора стрёмная. Я завтра попробую на живом максторе (Правда на ALPINE) с какой нибудь лабудой пересчитать его транслятор и отпишусь, сохранились данные или нет. Для полной уверенности.
pcmxpkr версии такой же.
О, спасибо огромное, это именно то, что нужно, потому что живого макстора у меня сейчас получается нет... Тогда может запишете и DMCS чужой (пересчитается ли он тоже, или только AT_PDL)?