У меня есть HP DL380p Gen8 под управлением Ubuntu 14.04, и, по-видимому, у него были проблемы с файловой системой RAID10 в течение почти месяца, хотя в остальном все, казалось, было в порядке. Я вижу много таких сообщений в dmesg
/syslog
/и т.д. хотя шестнадцатеричные значения в строках чтения немного различаются.
Nov 18 08:09:25 server03 kernel: sd 2:0:0:1: [sdb]
Nov 18 08:09:25 server03 kernel: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Nov 18 08:09:25 server03 kernel: sd 2:0:0:1: [sdb]
Nov 18 08:09:25 server03 kernel: Sense Key : Medium Error [current]
Nov 18 08:09:25 server03 kernel: sd 2:0:0:1: [sdb]
Nov 18 08:09:25 server03 kernel: Add. Sense: Unrecovered read error
Nov 18 08:09:25 server03 kernel: sd 2:0:0:1: [sdb] CDB:
Nov 18 08:09:25 server03 kernel: Read(16): 88 00 00 00 00 03 f8 48 f5 38 00 00 00 80 00 00
И iLO, и hpssacli сообщают, что все диски в порядке и файловая система не предназначена только для чтения. Устройство / dev / sdb представляет собой RAID10 с использованием RAID-контроллера сервера, состоящего из 20 дисков по 900 ГБ.
Это рабочий сервер, и хотя я один раз перезагрузил его, чтобы прояснить ситуацию, я не хочу пробовать fsck, не пытаясь определить, что означают эти сообщения, когда других очевидных проблем нет.
Итак, какие-нибудь мысли о том, что здесь может быть не так?
Хорошо, я отвечу обычными методами устранения неполадок, но вот мой отказ от ответственности:
Пожалуйста, укажите следующее в вашем вопросе или отдельном pastebin.
hpssacli ctrl all show config
.hpssacli ctrl all show config detail
.df -h
и fdisk -l
.lsscsi
.Поскольку вы используете Ubuntu, у вас, вероятно, не установлены агенты управления HP. Пока hpssacli
может обеспечить выборочную проверку состояния массива, hp-snmp-agents
пакет - это то, что обеспечивает фактический непрерывный мониторинг.
Если у вас установлены некоторые из агентов HP Health, запустите hplog -v
для извлечения журнала IML.
Я предполагаю, что вы используете сервер HP ProLiant DL380p Gen8 SFF с 25 отсеками. Не исправлены, многие из этих юнитов пострадали от сбоев контроллера Smart Array и кеша контроллера. Есть также некоторые важные обновления объединительной платы расширителей, которые необходимо запускать на этой платформе.
В конце концов я исправил это, размонтировав и воссоздав файловую систему, и я не видел никаких сообщений об ошибках с момента повторного включения приложения базы данных на сервере, даже после того, как оно воссоздало почти 4 ТБ данных с других узлов кластера. (Мне интересно, способствовали ли прошлые замены дисков на этом сервере каким-либо образом повреждению файловой системы.)