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 может банально упилиться, и тогда ваши данные осядут мириадой песчинок на стенках гермоблока и его воздушного фильтра. Обратитесь к специалистам. Даже у них могут встретиться кране трудно разрешимые проблемы. Если бы у нас не было заранее сделанных наработок по разблокировке технорежима, данные с этого накопителя так и не удалось бы восстановить даже если бы владелец не усложнил задачу, вскрыв гермоблок и занеся туда облако пыли.

Выражаю особую благодарность компании Асе за помощь в решении описанной проблемы и подготовке материала.