nick231
Junior Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Более менее сделал Dragon Fly 4. Залил файлы, сделал их чтение через генерацию md5 для будущих возможных проверок "MD5 Checksum Verifier'ом".
На освобожденном Sadle 6 что ранее отключал 5-ю голову в оригинальном P-листе было много секторных бэдов(по третьей поверхности) и операция переноса дефектов работала дольше чем на DF4(особенно когда все внутренние логи "красные"). Чтоб работало быстрее и для проверки корректности внесения в P-лист секторных дефектов(все же поверхность состарилась) - удалил из оригинального P-листа секторные дефекты, оставил трековые. Запустил на нем скрипт ss из E6, начиная с 3301(похоже с текущими параметрами - это пересчет транслятора с учетом P-листа, надо проверить изменения в трансляторе) и далее идут запись - чтение(увеличив в чтении число "переносов" до 32-х) и все друге команды что возможно прокатят. На сыром запуске тестовые команды начала скрипта отработали вероятно не очень хорошо. Прикол в том что кроме номера скрипта также изменилось и содержимое части параметров скрипта и он фактически перестал работать при последующих запусках. Т.е. SS скрипт из E6 надо возможно предварительно чистить от подобных выходных данных.
- >Запись (стирание) прошла нормально. Далее еще прошел быстрый тест судя по названию дополняющий логи P листом и начался длительный тест(3423).
- >По факту(и по названию) 3423 команда - перегоняет лог ss дефектов в G лист и далее в P лист(если дефектов много то очень медленно). И во время её выполнения возможен даже принудительный останов процесса и он продолжается с того же места если запустить SS тест без очистки логов.
Мне LBA дефекты из оригинального лога были не нужны, поэтому вернул только трековые дефекты и запустил скан дефектовки чтением. Но чуда не произошло. На пятой головке проблемы и лимит дефектов на ней вполне можно исчерпать, помимо того что скан был чрезвычайно медленный. Прервал скан. Головка с недавнего времени резко начала умирать (что не очень хороший признак для надежности хранения данных на этом HDD).
Вернул бэкап с отключенной головкой - поиграю еще с ним относительно предположения что часть заводских дефектов могут скрываться в процессе условной "микрополировки". Т.к. на ЕADS при запуске с дефектовки с нуля(и без существенных калибровок поверхностей), трековых дефектов в итоге стало меньше ~ на четверть по всем поверхностям кроме пятой.
Пока идет сканирование, решил сделать авто редактор для модуля 36(относительно замены битых треков в нем, удалить их конечно можно и не вникая в нюансы). Не могу понять логики дополнительных параметров к трекам в нем. По идее эти доп параметры должны быть расшифрованы в явном виде в софте PC-3000 (в котором есть редактор 36 модуля). Может у кого есть скрины или еще идеи?
В первом приближении, при создании соответствующих групп "хороших треков" (эти группы могут присутствовать не обязательно на всех поверхностях одновременно (надо больше примеров)) - надо учитывать число треков на поверхность (плотность записи). Алгоритм создания (поиска) таких групп не назвать примитивным для программного кода контроллера, но и сложным тоже не назвать. Если сократить простыню, то формируются группы блоков:
0 0 мелкий 0/4
1 0 мелкий 0/4 от мах числа треков
2 0 большой 0/4
1 1 мелкий 1/4
0 1 мелкий 2/4
1 2 мелкий 2/4
2 1 большой 2/4
1 3 мелкий 3/4
0 2 мелкий 4/4
1 4 мелкий 4/4
2 2 большой 4/4 от мах числа треков
по каждой головке, вероятно с учетом числа треков на поверхность. Первые два параметра полагаю задают последовательность скана треков от 00, 01, ... до 22.
Цитата:
Какая команда создает с нуля, правит 36 модуль?
[Вероятно команда создания 36 модуля - будет работать только по предварительно генерированному логу трековых или секторных дефектов, а команды правки модуля 36 - вероятно работают по итогам команд дополняющих трековые дефекты, на основе количества секторных дефектов в Р-листе] |
Всего записей: 65 | Зарегистр. 31-08-2020 | Отправлено: 17:37 18-09-2020 | Исправлено: nick231, 12:25 19-09-2020 |
|
