ARES C64K: слетели P-List и DMCS

Сделал очистку P-list&G-list, сразу вывалилось сообщение об ошибке. Но после этого винт стал определяться нормальным именем (в т.ч. в БИОСе)!! Появились нормальные номера цилиндров (мин/макс 376/83911) в логе и в верхней строке аси.

Некоторые изменения в служебке:

Изменилась RZTBL.

Изменились UBA некоторых модулей - 3-х Tbl_55AA и "OPTI - настройки SelfScan".
Сами модули тоже изменились.

P-list (AT_PDL) - контр. сумма ОК, сам AT_PDL очистился, по крайней мере 768 байт из 1024.
P-list (список) - как в прошлый раз (понятно, он берется из 33 модуля).

G-list (AT_POL) обнулен, G-list (список) ес-но пустой.

U_LIST - по сравнению с родным изменен.

DMCS - по сравнению с чужим изменен.

Модуль 33. Измененные сектора 33-48 остались + изменились несколько байт чуть дальше.

SMART Attributes - изменился 1 байт

Появилась мысль сделать посекторную копию винта с помощью dd_rescue (вместо бэдов будут нули). Потом пробовать пересчитать транслятор. Если что-то не пойдет, будет хотя бы образ. Родные P-list и G-list есть - в теории можно будет пропустить/заменить эти участки (правда конечно слабо еще это себе представляю)...

1. Как вам такая идея? Я ничего не сломаю, если загружу линукс и сделаю посекторную копию? Линуха по идее не должна писать на винт?

2. То, что съехали UBA некоторых модулей - это связано с RZTBL? Или это не есть хорошо?

Что значит аппаратно? (Я чистил через меню аси.)

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

По p-listу и образу - теоретически можно, а вот практически...

Надо по CHS дефекта вычислить LBA, затем его выкусить из образа со сдвигом "хвоста" на один этот сектор. Если есть скрытый трэк, сдвигать надо на длину этого трэка. В общем - задача весьма нетривиальная.

Насколько знаю линукс, при загрузке он пытается подмонтировать том, а затем пустить проверку файловой системы.
Я в таких случаях пользую голый дос и dfsee для dos. Медленно, правда.

Похоже, винт 33-й модуль не считывает правильно. Эти сектора, которые изменились лежат на сбойном участке, который плохо читается. Не зря винт при попытке очистить P-List дал ошибку. Попробуй проверить поверхность по этому модулю (группе). Если при проверке притормаживает на этом месте - возможно плохо читает.

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

Да, я тут уже часа два сидел соображал, как это все сделать Много нового узнал

Если ты имеешь в виду, что исключена целая дорожка и допустим часть следующей... В таблице P-list кроме CHS еще есть длина. И по-моему (судя по докам) в этом случае в таблице просто будет одна запись с увеличенной длиной вместо двух (одна - для целой дорожки и одна - для части следующей) для экономии таблицы. Так что тут проблемы не вижу. Или ты другое имел в виду?

Да и у меня, судя по родному п-листу, такого нет.

А вот другой вопрос интересный... Внутри винт работает по CHS, а по интерфейсу - по LBA, так? Т.е. приходит запрос на некий LBA, а винт выполняет трансляцию LBA->CHS. При этом нужно Число секторов на дорожке, которое в разных зонах диска разное, поэтому оно берется из RZTBL, так? У меня RZTBL изменилась. Т.е. винт может переходить на следующие дорожки позже/раньше, чем надо. Т.е. если я сейчас сниму образ, некоторые сектора возможно будут пропущены/лишние? Или еще хуже - что-нибудь заглючит. Получается, перед снятием образа надо вернуть родную RZTBL? Ответьте кто знает плиз!

По G-list'у... Я могу прочитать резервную область (после макс. LBA), чтобы потом в образе заменить дефектные сектора, скрытые в G-list'е? (Понятно, что G-list некритичен для данных.)

По переводу CHS->LBA подскажите кто знает (саму формулу я нашел)... Вот фрагмент P-list'а:

  #    Cyl    Head   Sec   Length
---------------------------------
  1    1104     3       0    928

Почему номер сектора - 0? Я вообще читал, что он может принимать значения 1-63. Или это только при старой CHS-адресации через интерфейс (через регистры IDE)?

И в целом по винтам такой вопрос, не нашел. Вот у меня в строке статуса аси показывается мин. цилиндр = 376, макс. = 83911. Смотрю лог служебки, таблицу зон (номера цилиндров):

316-375
376-9504
.......
80147-83911

Область данных, доступных пользователю - это цилиндры 376-83911?

Резервная зона - после 83911?

Где служебка - на цилиндрах 316-375?

Что находится перед цилиндром 316?

Не выдумывайте, голову сломаете...
В резервной зоне тоже могут быть дефекты.
Нужно потом просто вернуть, если сохранился, родной G-лист. а на нет и суда нет.
Формулы LBA>CHS нет.
Есть транслятор (таблица), как раз для этого преобразования. И команды которые возвращают запрошенное значение LBA или CHS соответственно.
У вас одна голова у HDD, а у многоловых LBA идут змейкой, вперед-назад по разным головам. Не знаю как на Аресе, но на многих хардах зоны не попорядку, а по уменьшению плотности привязаны к LBA. Есть и еще всякие подводные камни, например, цилиндры оставленные для самотестирования, которые вобще в других таблицах (не в листах дефектах), но учтенные в трансляторе.
Если транслятор не родной, то разобраться между реальностью и тем что видишь вобще невозможно. Если б в каждом секторе хранился его адрес по LBA, только тогда, а такого нет.

Просто я не знаю, что будет с винтом дальше, поэтому я и хотел вытянуть хоть что-то, пока он определяется в БИОСе... Мне ведь данные с него нужны.

Ну что, тогда делаю так:
1. Заливаю родной 33.
2. Пересчет транслятора.
3. Заливаю родной G-list (AT_POL).

Я прав?

Я прав?

По идее - да. Другого пути всё равно нет. Смущает только то, что при пересчёте транслятора винт давал ошибку. Впрочем, в нормальном режиме может всё пройти хорошо.
В принципе, могу попробовать на своём максторе и посмотреть, что получится.