Диагностика состояния диска с помощью Smartctl
Как определить, есть ли на диске проблемы с использованием Smartctl?
У меня есть сервер Ubuntu 12.04 с программным обеспечением RAID1, который стал полностью не отвечает. Я перезагрузился, и он завис при загрузке с сообщением "/tmp не готов или отсутствует", поэтому я пропустил и запустил терминал ручного восстановления. Все выглядело хорошо, за исключением того, что моя повторная синхронизация RAID была ужасно медленной. Тем не мение, cat /proc/mdstat не показывал никакого фактического сбоя RAID.
Я натолкнулся /proc/sys/dev/raid/speed_limit_min следуя инструкциям здесь, но это не слишком помогло. Мой массив размером 1 ТБ был повторно синхронизирован в течение 30 минут, но он завершен только на 0,3%.
Итак, я установил smartmontools и проверил диски, используя:
sudo smartctl --all /dev/sda
sudo smartctl --all /dev/sdb
Оба сообщают о состоянии "PASSED", но sdb также показывает несколько строк, таких как:
Error 83 occurred at disk power-on lifetime: 15147 hours
Error 82 occurred at disk power-on lifetime: 15147 hours
Error 81 occurred at disk power-on lifetime: 15147 hours
Error 80 occurred at disk power-on lifetime: 15147 hours
вместе с каким-то шестнадцатеричным дампом для каждого.
Что это значит? Должен ли я интерпретировать эти ошибки, чтобы означать, что мой диск SDB умирает? Как мне это подтвердить?
Изменить: Также связано, с момента аварии, я теперь не могу подключиться к серверу SSH. Я могу получить к нему доступ просто с физического терминала, и, похоже, нет чрезмерной нагрузки. Я убедился, что брандмауэр отключен, и я все еще могу пропинговать сервер, но ssh myuser@myserver приводит к "Тайм-ауту соединения".
4 ответа
Если один из дисков выпал из рейда, вероятно, есть причина. Я бы заменил неисправный диск (звучит как sdb) и вместо этого восстановил бы его. На умных данных.
Есть большой раздел в smartctl -a вывод на интеллектуальную структуру данных. Это большая матрица слов и цифр, которая сообщает вам текущие пороговые значения для конкретных тестов. Вот некоторые из тех, на которые стоит обратить внимание:
- Raw_Read_Error_Rate (id 1)
- Reallocated_Sector_Ct (id 5)
- Spin_Retry_Count (id 10)
- Reported_Uncorrect (id 187)
- Offline_Unc корректируемый (id 198)
Все это относится к проблемам с поверхностью диска (кроме идентификатора 10, который относится к двигателю шпинделя). Поверхность диска, скорее всего, выйдет из строя всех вещей на диске. Если какой-либо из них является чрезмерно высоким (в сотнях или тысячах), вы точно знаете, что есть большая проблема.
Регистры внизу выглядят примерно так:
ER ST SC SN CL CH DH - - - - - - - 40 51 00 ff ff ff 0f Ошибка: UNC на LBA = 0x0fffffff = 268435455
В этом случае на диске произошла ошибка UNC (неисправимая ошибка чтения / записи).
Мое мнение таково, что если вы видите что-то подобное:
Ошибка 518 произошла при включении диска: 16859 часов
... диск следует заменить, когда это удобно.
Проблема SSH может быть связана с диском (возможно, поврежденная часть находится под двоичным файлом SSH), но это, скорее всего, что-то еще, что вы должны исследовать отдельно.
Что касается вашей резервной копии - ожидание ошибки SMART или предупреждение слишком поздно, чтобы сделать резервную копию. Лучшие практики включают проверенный план резервного копирования и достаточную избыточность в подсистеме хранения для обработки ожидаемых сбоев оборудования.
Многие из атрибутов в таблице атрибутов SMART являются полезными индикаторами неисправных дисков. Не могли бы вы обновить ваш пост выводом "smartctl -data -A /dev/sdb"? Таблица атрибутов зависит от диска, поэтому я не могу перечислить те, которые будут релевантными, кроме довольно общих, таких как 'Reallocated_Sector_Ct', 'Offline_Uncorrectable' и т. Д. На странице Википедии в SMART содержится описание большинства атрибутов.
Самодиагностика SMART, которая quadruplebucky также полезна, но эти счетчики атрибутов могут сразу сказать вам, если диск выходит из строя. Возможно, накопитель не вызовет общее предупреждение о работоспособности SMART, но все равно будет находиться на выходе.
Убедитесь, что вы сделали резервную копию прежде всего.
Что касается ошибки / tmp, это известная ошибка:
https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1091792
Re: SMART ошибки:
Получить длинный тест: smartctl -t long /dev/sdb
Вы можете запустить это в любое время. Это займет некоторое время. Посмотреть результаты с smartctl -l /dev/sdb когда это будет сделано.
И, конечно, убедитесь, что вы зарезервированы прежде всего.
Из того, что вы опубликовали, меня больше всего беспокоит то, что у вас, похоже, внезапно возникло множество ошибок (при активности диска менее 2 лет). Однако неисправный диск не должен разрушать вашу систему (на самом деле вы должны видеть много других шумов в журналах в то время, когда он замерзает). Случайные ошибки вполне нормальны, и в то же время многие из них вызывают беспокойство.
SMART иногда полезен для раннего предупреждения, вы, конечно, не можете полагаться только на него.
Так что не мешало бы снова отступить. Но я не думаю, что у тебя есть основания для паники.