17 окт. 2011 г.

Что можно узнать о SAS диске?

Часто задаваемый вопрос: "есть ли у SAS-дисков SMART и как его посмотреть?"
Да, в некотором виде есть, в виде лог-страниц с различной полезной информацией. В статье будет рассказано о том, как эту информацию получить и интерпретировать.

Хочется подчеркнуть что, речь ниже пойдет не о домашних пользователях, для которых регулярная проверка здоровья и производительности родного железа может быть чем-то вроде хобби. Да и в случае появления признаков неисправности на том же HDD первой мыслью будет не "немедленно списать и заменить", а "сколько он еще протянет и нельзя ли как-нибудь его починить?". Такой подход вполне имеет право на жизнь, ведь ценность "домашних" данных и объем IT-бюджета, как правило, не очень высоки.
Ситуация в корпоративном секторе или в гарантийном отделе поставщика (как раз наш случай) будет немного другой. Хорошему администратору совершенно не должно быть интересно, к примеру, значение SMART-атрибута Seek_Error_Rate на диске. Логика действий проста: получив информацию от RAID-контроллера о проблемах с диском, выкинуть его из массива и запустить ребилд на новый диск (эту процедуру можно и оптимизировать). Подробности сбоя и "нельзя ли как-нибудь его починить?" никого не интересуют - стоимость потери данных и/или возможного простоя просто не позволяют адекватному сотруднику тратить время на подобные вопросы.
И все же дальнейшая судьба сбойнувшего диска - диагностика. В ней может быть заинтересован либо владелец (например, с целью пристроить более-менее живой диск для каких-либо "небоевых" нужд) и, конечно, гарантийный отдел поставщика - при этом диски могут поступать не по 1-2, а десятками. А проверить нужно в ограниченные сроки, т.е. одновременно по нескольку штук, так что времени на последовательную проверку через MHDD, HDDScan, различные утилиты от производителей и format/verify средствами контроллера просто нет.

Софт
И так - диагностика. Алгоритм простой - смотрим нужные счетчики, отправляем диск на форматирование, проверяем поверхность, снова смотрим счетчики на предмет роста ошибок. Для начала желательно собрать о "пациенте" побольше сведений. IMHO, лучший инструмент для этого - пакет smartmontools (в состав которого входит утилита smartctl):
  • Изначально разрабатывался под Linux, но на данный момент портирован на большое количество платформ, включая различные *BSD и Windows. Кстати, для тех, кто предпочитает GUI - под Linux/FreeBSD/Windows есть отличный фронтенд GSmartControl
  • Выводит подробную информацию о диске, включая не только SMART-атрибуты (с расшифровкой многих нестандартных атрибутов), но и страницы с логами ошибок.
  • Позволяет запускать поддерживаемые современными ATA и SCSI дисками внутренние тесты самодиагностики (short selftest и long selftest).
  • Может работать как при прямом подключении диска, так и через различные USB и Firewire конвертеры. Версии под Linux и FreeBSD позволяют "достучаться" до дисков, подключенных к различным RAID контроллерам (3ware, Areca, HighPoint, HP Smart Array, LSI MegaRAID).
  • Может выводить в удобочитаемом виде некоторые лог-страницы SCSI-дисков (к которым, естественно, относится и SAS) - что нам и нужно.
Инструмент номер два - пакет sg3_utils, набор утилит для работы со SCSI-устройствами. Пакет портирован под большое количество ОС, включая Windows. Во многих дистрибутивах Linux присутствует устаревшая на 1-2 года версия, но последнюю легко собрать из исходников. Для наших задач представляют ценность следующие утилиты:
  • sg_logs - выводит лог-страницы устройства в более подробном виде, чем smartctl. Пример вывода с разъяснениями будет ниже
  • sg_format - выполняет форматирование диска. При очень большом желании можно изменить объем и даже размер сектора.
  • sg_verify - выполняет недеструктивную проверку выбранных блоков командой SCSI VERIFY.
  • sg_reassign - ручной ремап нужных блоков через SCSI-команду REASSIGN BLOCKS с помещением в Grown defect list
  • sg_senddiag - отправка команд на запуск встроенных тестов (то же, что и smartctl --selftest для ATA дисков).
Оборудование и ОС
В качестве оборудования подойдет любой SAS HBA, т.е. простой контроллер, без аппаратного RAID или с отключаемым хост-RAID'ом. В TrueSystem используются LSI 9211 или набортные контроллеры на базе чипов LSI 2008 или 1068E (с IT-прошивкой). Изредка в гарантию попадают диски под параллельный SCSI, на этот случай под рукой есть Adaptec AHA2930 и переходник с 68pin на SCA.
Операционная система - вопрос личных предпочтений. Вышеуказанные утилиты имеют порт под Windows, но в Linux с ними работать чуть удобнее. При параллельном тестировании множества дисков возникает проблема неудобства множества консольных сессий. Решение для Windows - терминал Console, для Linux/FreeBSD показался удобным удаленный доступ через SSH (если с Windows - через PuTTY) и запуск в SSH-сессии консольного менеджера screen.

Проверяем
Пациент номер один: относительно 300ГБ старый U320-SCSI диск Fujitsu MAW3300NC. Подключаем и определяем, где его искать (через lsscsi или sg_scan). Далее можно посмотреть на вывод smartctl или sg_logs. Начнем со smartctl:
# smartctl -a /dev/sdb
Vendor:               FUJITSU
Product:              MAW3300NC
Revision:             0104
User Capacity:        300,000,000,000 bytes [300 GB]
Logical block size:   512 bytes
Serial number:        DA00P8B037VT
Device type:          disk
Transport protocol:   Parallel SCSI (SPI-4)
Local Time is:        Fri Oct 14 16:35:21 2011 MSK
Device supports SMART and is Disabled
Temperature Warning Disabled or Not Supported
SMART Health Status: FIRMWARE IMPENDING FAILURE TOO MANY BLOCK REASSIGNS [asc=5d, ascq=64]

Current Drive Temperature:     26 C
Drive Trip Temperature:        65 C
Manufactured in week 45 of year 2008
Specified cycle count over device lifetime:  10000
Accumulated start-stop cycles:  8

Elements in grown defect list: 8191

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:          0 39965378      3599         0          0     345061.500        3599
write:         0        9         0         0          0      45798.649           0
verify:        0      210         1         0          0          0.026           1

Non-medium error count:       25
No self-tests have been logged
Long (extended) Self Test duration: 6325 seconds [105.4 minutes]
 
Примерно тоже можно было бы получить, запустив sg_logs -a, для SAS дисков - с добавкой в виде страницы Protocol Specific port log page for SAS SSP, где перечислены оба phy SAS диска (если он 2-портовыйСразу в глаза бросаются огромное количество ошибок чтения, большое кол-во ремапов (Elements in grown defect list) и предупреждение "SMART Health Status: FIRMWARE IMPENDING FAILURE TOO MANY BLOCK REASSIGNS [asc=5d, ascq=64]". Последнее хранится на странице Informational exceptions в логах диска и говорит нам о том, что дальше его можно и не тестировать: алгоритм, заложенный в firmware уже сделал вывод о предсмертном состоянии диска по большому количеству ремапов.
Отличное от нуля значение счетчика Non-medium error count не всегда указывает на проблемы с диском. Было несколько случаев с SAS-дисками и контроллером Adaptec, когда причиной был некачественный noname кабель.
Можно еще немного помучить диск, запустив самодиагностику, например "длинный" фоновый тест:
# sg_senddiag --selftest=2 /dev/sdb
Тест прерывается с ошибкой о найденных бэдах, о чем можно узнать, запустив
# sg_logs -a /dev/sdb
и посмотрев на соответствующую страницу:
Self-test results page
  Parameter code = 1, accumulated power-on hours = 20912
    self-test code: background extended [2]
    self-test result: another segment in self test failed [7]
    self-test number = 3
    sense key = 0x6, asc = 0x5d, asq = 0x64
Собственно, при помощи smartctl со SCSI/SAS дисками можно сделать то же, что при запуске sg_logs и sg_senddiag - посмотреть логи и запустить self-test'ы.
Следующий шаг - форматирование. Запускаем
# sg_format --format /dev/sdb
и ждем окончания. Собственно форматированием занимается firmware диска, для SCSI/SAS данная процедура является самым верным способом заставить диск заремапить все сбойные сектора. Именно ту же процедуру выполняет, например, контроллер Adaptec при выборе в меню пункта "Format disk", только в данном случае мы имеем информацию о ходе выполнения и, что самое важное - возможность форматировать несколько дисков. Многие современные диски SAS (например, Hitachi) понимают некоторые SCSI команды и могут работать с утилитами sg_format и sg_verify, только вот ручной ремап через sg_reassign не воспринимают (его можно сделать при помощи hdparm).
В данном случае форматирование завершилось успешно (сообщение FORMAT COMPLETE после 99%), смотрим в логи и видим, что счетчик Elements in grown defect list уменьшился до 166 (просто данные о ремапах были перенесены в p-list). Нужен еще один тест поверхности. Вместо selftest'а можно попробовать что-нибудь наглядное, например badblocks в деструктивном режиме:
# badblocks -svw /dev/sdb
При запуске с этими ключами badblocks совершит 4 пары проходов по диску, записывая и считывая различные паттерны. Занимает очень много времени (5,5 часов для этого диска и почти двое суток для 2ТБ диска).
Итак - 13 бэдов, снова смотрим в логи, видим растущее количество ремапов ошибок чтения. Для очистки совести можно запустить еще раз badblocks или внутренний тест и убедиться в том, что диск по-прежнему находится в совершенно плачевном состоянии. Можно его остановить перед отключением командой
# sg_start --stop /dev/sdb
и отправить в утиль.