Да, в некотором виде есть, в виде лог-страниц с различной полезной информацией. В статье будет рассказано о том, как эту информацию получить и интерпретировать.
Хочется подчеркнуть что, речь ниже пойдет не о домашних пользователях, для которых регулярная проверка здоровья и производительности родного железа может быть чем-то вроде хобби. Да и в случае появления признаков неисправности на том же 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) - что нам и нужно.
- 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
В данном случае форматирование завершилось успешно (сообщение FORMAT COMPLETE после 99%), смотрим в логи и видим, что счетчик Elements in grown defect list уменьшился до 166 (просто данные о ремапах были перенесены в p-list). Нужен еще один тест поверхности. Вместо selftest'а можно попробовать что-нибудь наглядное, например badblocks в деструктивном режиме:
# badblocks -svw /dev/sdb
Итак - 13 бэдов, снова смотрим в логи, видим растущее количество ремапов ошибок чтения. Для очистки совести можно запустить еще раз badblocks или внутренний тест и убедиться в том, что диск по-прежнему находится в совершенно плачевном состоянии. Можно его остановить перед отключением командой
# sg_start --stop /dev/sdb
Добрый день.
ОтветитьУдалитьХочу сообщить об ошибке (или заблуждении - как угодно) в данной статье.
Утверждение "В данном случае форматирование завершилось успешно (сообщение FORMAT COMPLETE после 99%), смотрим в логи и видим, что счетчик Elements in grown defect list уменьшился до 166 (просто данные о ремапах были перенесены в p-list)." - не корректно.
Ни один из существующих на рынке современных SCSI/SAS/FC-AL накопителей *НЕ* выполняет слияние дефект-листов (Merge G-to-P) при запуске стандартной команды FORMAT UNIT.
В user-прошивках перенос может быть осуществлен только в технологическом режиме работы спец.командой (автоматически), либо программно в случае использования серьезного спец.софта.
По факту, FMTU выполняет обычную запись user-пространства (ключая spare-зону) и если был указан параметр "Format using P+G List" - то набежавшие в работе grown-дефекты могут быть удалены диском из G-List`а, если их перезапись и последующее чтение прошло без ошибки (pending remove). Дефолтный же запуск команды FMTU вообще приводит к очистке (созданию пустого модуля) G-List`а перед началом форматирования и он может быть заполнен новыми записями уже в процессе форматирования.
В целом, приятно было почитать эту и многие другие статьи в блоге.
С уважением,
Маврицин Михаил
Профессиональный реверс-инженер и исследователь HDD
shakemind@mail.ru
Спасибо за информацию, Михаил!
УдалитьЭто многое проясняет, статью подправлю.
Дмитрий, как такое может быть? smartctl показывает
ОтветитьУдалитьSmart support is: Unavailable - device lacks SMART capability.
А тот же HDDScan все показывает.
Диск ST3450857SS
Какой версии smartctl и под какой ОС? Под Windows, действительно, до некоторых SAS дисков достучаться не удавалось. Используйте Linux и/или пакет sg3_utils, он под Windows тоже есть.
Удалить