3

Уже несколько лет мы запускаем программный RAID1 на старой коробке Gentoo с пользовательским Linux 2.6.31. RAID состоит из 2 жестких дисков с 4 разделами в каждом. В последние годы примерно 3-4 раза случалось, что диск выбрасывался из массива. Но каждый раз, когда badblocks не сообщал об ошибке, и я смог снова активировать диск, как это

mdadm /dev/md3 -r /dev/sda3
mdadm /dev/md3 -a /dev/sda3

На этот раз ситуация другая: mdadm сообщил о 2 неисправных разделах за последние 24 часа, оба на одном и том же диске sda . Я снова badblocks запускал бадблоки : он сообщил о 0 блоках. Если я пытаюсь добавить неисправный диск обратно в массив, он каждый раз вылетает с одной и той же ошибкой:

Mar 25 23:09:10 xen0 kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Mar 25 23:09:10 xen0 kernel: ata1.00: irq_stat 0x40000001
Mar 25 23:09:10 xen0 kernel: ata1.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
Mar 25 23:09:10 xen0 kernel: res 51/04:00:38:df:f7/00:00:00:00:00/a7 Emask 0x1 (device error)
Mar 25 23:09:10 xen0 kernel: ata1.00: status: { DRDY ERR }
Mar 25 23:09:10 xen0 kernel: ata1.00: error: { ABRT }
Mar 25 23:09:10 xen0 kernel: ata1.00: configured for UDMA/133
Mar 25 23:09:10 xen0 kernel: ata1: EH complete
Mar 25 23:09:10 xen0 kernel: end_request: I/O error, dev sda, sector 18297870
Mar 25 23:09:10 xen0 kernel: md: super_written gets error=-5, uptodate=0
Mar 25 23:09:10 xen0 kernel: md: md3: recovery done.
Mar 25 23:09:10 xen0 kernel: RAID1 conf printout:
Mar 25 23:09:10 xen0 kernel: --- wd:1 rd:2
Mar 25 23:09:10 xen0 kernel: disk 0, wo:1, o:0, dev:sda3
Mar 25 23:09:10 xen0 kernel: disk 1, wo:0, o:1, dev:sdb3
Mar 25 23:09:10 xen0 kernel: RAID1 conf printout:
Mar 25 23:09:10 xen0 kernel: --- wd:1 rd:2
Mar 25 23:09:10 xen0 kernel: disk 1, wo:0, o:1, dev:sdb3

Сектор всегда один и тот же: 18297870 . Если я проверю вывод команды smartctl -a /dev/sda он не показывает перераспределенных секторов, поэтому я подумал, что мог бы осуществить перераспределение с помощью метода, который нашел здесь .

hdparm --read-sector  18297870 /dev/sda
hdparm --write-sector  18297870 --yes-i-know-what-i-am-doing /dev/sda

Но с помощью приведенных выше команд диск вообще не сообщает об ошибке и, следовательно, не перераспределяет сектор:

smartctl -a /dev/sda | grep -i reall
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0

Я погуглил сообщение о status: { DRDY ERR } и некоторые говорят, что это может быть ошибка ядра. Но потом я удивляюсь, почему это только начало происходить сейчас. За последние годы в системе не было никаких изменений.

Но есть одна вещь, которая все еще меня беспокоит : smartctl -a /dev/sda также сообщает о некоторых ошибках в журналах. Это всегда одна и та же ошибка:

Error 15 occurred at disk power-on lifetime: 39971 hours (1665 days + 11 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 51 00 38 df f7 a7

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  ea 00 00 00 00 00 00 08  35d+12:17:45.571  FLUSH CACHE EXT
  61 80 f0 0e 96 2d 00 08  35d+12:17:44.033  WRITE FPDMA QUEUED
  61 80 e8 8e 95 2d 00 08  35d+12:17:44.033  WRITE FPDMA QUEUED
  61 80 e0 0e 95 2d 00 08  35d+12:17:44.033  WRITE FPDMA QUEUED
  61 80 d8 8e 94 2d 00 08  35d+12:17:44.033  WRITE FPDMA QUEUED

Все это не имеет смысла для меня: если диск действительно неисправен, то почему я могу успешно читать и записывать в сектор, в котором повторная синхронизация RAID происходит каждый раз? И почему диск сначала не пытается перераспределить поврежденный сектор, если он действительно обнаруживает ошибку?

1 ответ1

1

В этом вопросе задается вопрос о том, как восстановить диск, с которого был сброшен RAID, и вопрос о том, как диск может периодически выпадать из RAID, если проблем в секторе не существует. Чтобы начать понимать, что может происходить, может быть полезно понять, что вполне вероятно, что накопители перейдут в режим долгосрочного восстановления после ошибки или калибровки и перестанут отвечать на запросы в течение достаточно длительного периода времени, когда контроллер RAID выйдет из строя диск, хотя на нем нет ошибок мультимедиа.

Если диск не предназначен для использования в RAID-массиве, периодической операции самопроверки может быть достаточно для выхода из строя диска. Этот параграф ссылается на проблему:

https://en.wikipedia.org/wiki/RAID#Integrity

Эта 49-дневная ссылка на ошибку описывает пресловутый случай сбоев RAID, вызванных TLER.

Диски, специально предназначенные для RAID, ограничивают время, в течение которого диск может отключаться для выполнения операций обслуживания / восстановления.

При покупке диска для использования в RAID-массиве и во избежание подобных проблем полезно искать ограниченное по времени восстановление после ошибок (TLER) в спецификации диска.

Проблема TLER не объясняет сложность перестройки массива, однако рассмотрим ситуацию, когда диск выдерживает сбой сектора, а микропрограмма диска перераспределяет сбойный сектор на резервный, так что диск продолжает выглядеть "идеально". Можно задаться вопросом, был ли сектор 18297870 перенесен в резервный сектор и доступ к резервному сектору по какой-то причине занимает слишком много времени. Это кажется немного надуманным, но знание того, что временные задержки доступа к диску могут нанести ущерб RAID-массивам, может стать ключом к выяснению происходящего.

Проверьте выпущенные производителем обновления прошивки для накопителей. Обновления встроенного программного обеспечения не всегда доступны для накопителей потребительского класса, но накопители серверного класса часто получают обновления встроенного ПО, которые исправляют ошибки встроенного ПО, которые вызывают эксплуатационные проблемы, даже если сбой оборудования не произошел. Поиск по сети терминов "ошибка микропрограммы накопителя RAID dropout" приводит к значительному количеству совпадений. Некоторые результаты определяют конкретные марки и модели накопителей.

Эта ссылка документирует один случай дефекта прошивки, который вызвал сбой RAID. Хотя эта проблема не идентична проблеме, описанной выше, в статье показано значение микропрограммного обеспечения как возбудителя проблем RAID. См. Также страницу википедии Seagate Barracuda, которая содержит множество ссылок на ошибки микропрограммы накопителя, вызвавшие проблемы с производительностью.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .