Спасибо за ответы! Да, знаю, что они кривоватые, ... POST280826

Спасибо за ответы!

Цитата:

А Ares настоятельно рекомендую сменить.отжили они своё(это переходная модель с новыми не отработанными до конца изобретениями инженеров-разработчиков компании Maxtor)

Да, знаю, что они кривоватые, форумов начитался уже

Винт не мой, но после восстановления надо будет его положить на полочку - у него в P-list'е 487 дефектов, в G-List'е 34. У моего Calypso, например, в G-list't было всего 5 дефектов.

Alexander_G, спасибо.

Про смещение секторов в случае скрытия через P-list (и про замещение, если через G-list) в курсе - читал документацию. Для восстановления инфы дефекты в P-list'е критичны, в G-list'е - не очень.

Цитата:

Тем более нельзя записывать P-List от другого (и тем более пересчитывать транслятор), сектора скроются совсем другие и данные разрушатся совсем.

А как же тогда это (из документации к PC3000)?

Но вернемся к Maxtor. Данные программы транслятора находятся в следующих модулях: U_LIST (PN=37h), AT_PDL (PN=18h) и RZTBL (PN=78h). Накопитель формирует транслятор через промежуточную таблицу, имеющую PN=33h. В этой таблице дефекты указаны в их обычном представлении: цилиндр, головка, сектор. Существует возможность собрать таблицы транслятора из этой промежуточной таблицы при помощи команды “Пересчет транслятора” ...

Еще:

Задача восстановления транслятора возникает в случае, когда таблицы транслятора содержат неверные данные или не читающиеся сектора.
В такой ситуации возможно формирование таблиц транслятора на основе сводной таблицы дефектов (модуль PN=33h) при условии, что она не повреждена.
Чтобы запустить пересчет транслятора, необходимо выполнить команду “Пересчет транслятора” ...

Цитата:

Особенно, если на диск произойдет запись, на что винда горазда уже при загрузке совершенно не предупреждая юзера.

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

Цитата:

И ещё. У макстора p-list разбит на блоки и количество этих блоков прописывается в U-List'е, что приводит к трудностям правильной заливки p-lista взад, даже если он и родной, если это количество разбежится.

А вот про это, если можно, поподробнее. По идее, если P-list родной, то кол-во блоков будет соответствовать кол-ву блоков в U-List'е. Кроме того, судя по документации (см. выше), U-list также будет пересобран в ходе пересчета транслятора.

Цитата:

Обороты могут временно срываться из-за изношенных подшипников, тогда макстор наделает сектров в G-List'e и опять может не считаться всё правильно.

Ну тут уж как повезет... Но если даже он эти новые дефекты не зафиксирует в G-List'e, но для восстановления инфы это по идее не настолько критично - опять из документации:

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

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

Вход на сайт

Спасибо за ответы! Да, знаю, что они кривоватые,