SNOOOZZZZZZEEE Retry в терминале Seagate Grenada BP2
Поступил в работу жесткий диск Seagate ST2000DM001 который со слов заказчика не опознаётся системой. В диагностический терминал при старте выдается сообщение:
Boot 0x40M
Spin Up
RECOV Servo Op=0100 Resp=0005
Trans.
Spin Up
SpinOK
TCC:0018
RECOV Servo Op=0900 Resp=0005
SNOOOZZZZZZEEE Retry
SNOOOZZZZZZEEE Retry
SNOOOZZZZZZEEE Retry
SNOOOZZZZZZEEE Retry
No HOST FIS-ReadyStatusFlags 0002A1A
В регистрах busy. Троебуется, как обычно, восстановить информацию.
Приглашение "T>" при вызове выдается, однако подавляющее большинство технологических команд "залочены" в микрокоде. Ответ накопителя на "Ctrl+A":
Prod Desc: GrenadaBP2 LuxorLite 1.0, 1MB Flash, ABIE, PBASeed, DFW, SDnD
Package Version: G2AED3006.CCD4.GG08DY.
Serial #: S4Z04RF3
Changelist: 00647538
Model #: ST2000DM001-1ER164
ID: 101
Servo FW Rev: C64C
Heads: 4
PCBA SN: 0000K448JGH2
В данном состоянии ни о каком извлечении данных речи не идёт, так как накопитель не прогрузил служебную информацию и не готов к работе. Судя по сообщению "Trans.", основной исполнимый код с поверхности дисков считался и был запущен, что говорит о том, что головка 0 служебную информацию читать способна, судя по “No HOST FIS-ReadyStatusFlags 0002A1A1”, некоторые из критичных для запуска служебных файлов микропрограммы всё таки не были загружены в результате ошибки чтения. Причём, так как служебная информация представлена двумя копиями — по головкам 0 и 1, это говорит о критичных повреждениях набора служебных данных.
Из рассказа клиента следовало, что прямых механических повреждений накопителя не было, в то же время клиент, встретив проблему с доступом к данным, вскрыл крышку накопителя, нарушив его герметичность. После чего пытался его запускать. В таких условиях необходимо исследование гермоблока в чистой комнате. Ситуацию также осложняет то, что накопитель принадлежит к семейству Grenada. Данные накопители и без постороннего вмешательства склонны к механическим повреждениям поверхности. К примеру, при перегреве одна из голов при вращении диска может коснуться его полимерного покрытия (локально вспучившегося в результате воздействия повышенной температуры), после чего в месте касания образуется стремительно разрастающаяся область разрушений. При этом осколки с поверхности потоком воздуха в гермоблоке будут разнесены и на другие поверхности, в результате чего налетающие на них головки будут порождать новые запилы.
При осмотре в чистой комнате было выявлено ограниченное загрязнение головок 0 и 2, по-видимому, вызванное пылью, попавшей в гермоблок при вскрытии. Было принято решение о попытке очистки оригинальных головок. Данное решение обосновано тем, что загрязнения были небольшими, поддающимися очистке, не похожими на следы от запила поверхности. В то же время, попытка поставить сразу головки от другого накопителя-донора сразу привела бы к таким проблемам, как невозможность записи в служебную зону накопителя и гарантировано ухудшенное чтение, так как головки современных накопителей отличаются очень сильно даже в пределах одного блока голов, не говоря о блоках из разных HDD. В то же время запись в служебную зону для данного накопителя была необходима с целью восстановления критичных для запуска данных.
Перезапуск накопителя с помытыми головками показал, что необходимые данные по прежнему не читаются накопителем, в то же время новых загрязнений на головах 0 и 2 не появляется. Далее была предпринята попытка выявления, какие именно объекты служебной информации повреждены. Для этого необходимо было использовать определённый набор технологических команд, подаваемых в терминал накопителя. Дополнительной проблемой стало то, что исследуемый накопитель принадлежит к группе с заблокированным технорежимом. В этом состоянии технологические команды не исполняются, завершаются с ошибкой.
Если бы вся микропрограмма помещалась в ПЗУ, задача бы разрешалась его распаковкой, дизассемблированием, правкой и упаковкой. К сожалению, в ПЗУ находится только загрузчик основной микропрограммы, полностью заменяемый при её запуске. Таким образом, любой код, добавленный в ПЗУ будет или затёрт или никогда не получит управления после запуска основной микропрограммы.
Проблема решается многоступенчатым образом. На первом этапе в программу в ПЗУ добавляется дополнительный код, получающий управление после загрузки основного кода (с поверхности) в память, но до его размещения по рабочим адресам и запуска. Это позволяет проанализировать загруженный с поверхности микрокод в момент, когда код ПЗУ ещё существует в памяти. Далее было проведено дизассемблирование и исследование микрокода основной части микропрограммы. В результате были выявлены области кода, которые необходимо изменить для доступа к технокомандам и их признаки.
Изначально код основной части микропрограммы таких накопителей считывался через терминал, но при этом считывание занимало крайне длительное время, недопустимое при решении практических задач за это время диск-пациент мог запилиться. Поэтому было принято решение о написании отдельной программы, исполняемой процессором контроллера накопителя, в результате чего время, необходимое на разблокирование технологического режима резко сократилось.
После разблокирования технологического режима указанным выше образом было произведён анализ разрушений микропрограммы. Было выявлено, что повреждения были произведены накопителем в последние часы его работы в связи с нарушением функционирования записи на поверхность служебной зоны любые данные после попытки записи не читались. А так как запись идёт по всем копиям, то разрушения данных были полными.
Повреждены были данные конфигурации Media Cache, логи состояния, SMART, Debug, части транслятора (в частности, G-List). Была предпринята попытка восстановления служебных данных по сохранившимся логам, известным шаблонам конфигурации и очистка задействованных при работе многочисленных логов.
Может показаться, что работа с логами не важна для работы с накопителем. К сожалению в случае HDD Seagate это не так. При запуске микропрограмма читает многие из них, пытается разобрать, и если лог не считан или содержит внутри логическую ошибку в данных, происходит зависание кода или аварийное его завершение. Причём, если нечитаемость данных ещё отследить достаточно просто, то логические нестыковки в данных могут вызвать ошибку много времени позже и в совершенно постороннем коде.
Безоглядно же очищать или инициализировать все логи и таблицы также нельзя. Вся процедура анализа служебной информации и попытки её восстановления заняли несколько часов под постоянным прессом осознания, что в любой момент накопитель может начать пилить поверхность. Завершающим сюрпризом стало то, что при корректных исходных данных накопитель не может сформировать правильный транслятор пользовательской зоны. Причём в её начале и в конце транслятор сходился, но в середине в нескольких областях происходили смещения, приводящие к нечитаемости этих областей. Явление, скажем так, необычное. В конце концов удалось скомпенсировать и эти смещения и была начата кропотливая работа по вычитыванию пользовательских данных с накопителя, читающего с поверхности крайне нестабильно, с большим числом BAD блоков. В итоге удалось все необходимые пользователю данные.
Мораль сей басни такова — не пытайтесь вскрыть свой накопитель, если не можете получить с него данных. Не пытайтесь “завычитывать” его насмерть, если видите на нём нечитаемые области — HDD может банально упилиться, и тогда ваши данные осядут мириадой песчинок на стенках гермоблока и его воздушного фильтра. Обратитесь к специалистам. Даже у них могут встретиться кране трудно разрешимые проблемы. Если бы у нас не было заранее сделанных наработок по разблокировке технорежима, данные с этого накопителя так и не удалось бы восстановить даже если бы владелец не усложнил задачу, вскрыв гермоблок и занеся туда облако пыли.
Выражаю особую благодарность компании Асе за помощь в решении описанной проблемы и подготовке материала.
Читать так же:
Поддельные HDD из Китая
Покупка дешевого внешнего жёсткого диска из Китая
Опять о сгоревшем «контроллере» жесткого диска
К каким последствиям может привести то, что в просторечии называется «сгорел контроллер жёсткого диска»
Не могли бы вы написать каким средством промываете головки hdd.
Жидкостью для очистки которую Seagate распространяет по СЦ.
Внешний диск для хранения личных данных (семейные фото, backup-ы с устаревших или вышедших из строя ноутбуков и ПК с инфой «до лучших времен» и пр.), куплен около 2012 года. Использовался максимально бережно, не ронялся, не ударялся, включался и выключался при необходимости только лично (детям не доверял!!!) по инструкции производителя (в том числе — с предварительным программным отключением перед отсоединением), хранился в сейфе, так как уже был опыт поломки и восстановления чувствительных данных. Вероятно максимум часов 200-300 за все время проработал. При очередном включении обнаружен звук попыток головок начать чтение данных и последующего их возврата в исходное положение (до 10 попыток с одинаковым интервалом) и далее — выключение диска (то есть отсутствие каких либо звуков и признаков работы). Софт Victoria диск не обнаруживает. Отдавал на диагностику друзьям в Лабораторию Касперского (правда они не совсем специалисты по таким вопросам, но обещали хуже не сделать). Есть текстовое описание проделанной работы с приложением каких-то технических файлов (графики сигналов, аудифайлы звуков и пр.). В итоге посоветовали обратиться к Вам, так как у друзей с их слов с вашей организацией имеется положительный опыт взаимодействия. Могу предварительно переслать все отчеты. Есть возможность помочь?