LINUX.ORG.RU

Вылетел диск из аппаратного Рейда 10

 


0

1

Ситуация такая, вылетел диск с рейда 10 с подобной ошибкой, Контролер LSI MegaRAID SAS pike_2108

seqNum: 0x00004565
Time: Wed Sep 25 18:42:22 2024

Code: 0x00000057
Class: 1
Locale: 0x02
Event Description: Error on PD 07(e0xfc/s5) (Error f0)
Event Data:
===========
Device ID: 7
Enclosure Index: 252
Slot Number: 5
Error: 240

При обращению к SMART диска, была ошибка чтения

После перезагрузки сервера диск ожил и я его ресинхронизировал назад.

Из нюансов были ошибки файловой системы, и рост IO Delay, проблема исправлена FSCK.

Но не очень понятно в какую сторону теперь копать, на данный момент все работает стабильно ошибок более нет. SMART Диска HGST HUS728T8TALE6L4

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   016    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   132   132   054    Pre-fail  Offline      -       96
  3 Spin_Up_Time            0x0007   166   166   024    Pre-fail  Always       -       478 (Average 502)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       11
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   128   128   020    Pre-fail  Offline      -       18
  9 Power_On_Hours          0x0012   094   094   000    Old_age   Always       -       44685
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       9
192 Power-Off_Retract_Count 0x0032   099   099   000    Old_age   Always       -       1871
193 Load_Cycle_Count        0x0012   099   099   000    Old_age   Always       -       1871
194 Temperature_Celsius     0x0002   214   214   000    Old_age   Always       -       28 (Min/Max 20/48)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0

Кроме опции Spin_Up_Time ничего особо не смущает, ваше мнение в какую сторону копать, так как подобные проблемы любят возникать в будущем, раз уже ранее возникали.



Последнее исправление: Evgeniy39 (всего исправлений: 2)

Забей пока, диск лагнул и контроллер его дропнул.

Spin up time не знаю что такое но у тебя оно полностью в норме судя по числам.

После перезагрузки сервера диск ожил и я его ресинхронизировал назад.

Зачем перезагрузка? Добавил бы назад просто.

Или ты хочешь сказать диск не отвечал до ребута вообще в т.ч. на смарт? Можно попробовать переткнуть его в слот было.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 3)
Ответ на: комментарий от firkax

Все несколько хитрее, сработал скрипт проверки Рейда, в кроне выполняется команда на основе

/usr/sbin/megacli -LDInfo -L0 -a0 | egrep "State"

И действительно команда

megacli -LDInfo -L0 -a0

выдавала деградацию Рейда

Команда

megacli -PDlist -a0

выдавала дохлый диск

Считать именно с него SMART командой

smartctl -d megaraid,4 -a /dev/sda

не удавалось, как будто под этим ID не было диска.

Но что самое интересное сервер внешне не как не отображал сбойный диск, сигнализация не горела и не пищала, внешне диски весело перемигивались (как будто все хорошо), попытка подсветить Слот успехом не увенчалась. И поэтому я его решил перезагрузить, так как дернуть рабочий диск не хотелось. Возможно для данного сервера, а это был Азус, такое поведение и нормально, просто привык к Супермикро, они хорошо сигнализируют о проблемах. После перезагрузки диск стал отвечать на запрос smartctl, соответственно далее с помощью megacli я его перевел из разряда fail в Good а далее Rebild в рейд. Но что еще меня удивило как только ресинхронизация закончилась и рейд перешел в Optimal посыпались ошибки файловой системы и начали расти задержки ввода вывода. Собственно ошибка ;

EXT4-fs error (device sda): htree_dirblock_to_tree:884: inode #248651484: block 85: comm afpd: Directory hole found for htree leaf block

Проблема решил FSCK, но первый раз вижу что при переходе с degraded в optimal подхеривалась файловая система.

Evgeniy39
() автор топика
Ответ на: комментарий от Evgeniy39

выдавала дохлый диск

А конкретнее? Я не видел megacli, но у storcli есть команда set good, которая отменяет bad статус и контроллер пытается дальше работать с диском.

Азус

Что это?

но первый раз вижу что при переходе с degraded в optimal подхеривалась файловая система.

Да, это странно. Может с контроллером проблемы?

firkax ★★★★★
()
Ответ на: комментарий от firkax

Чтоб нормально вернуть диск он должен быть ресинхронизирован в Рейд, так как он после того как получает статус Fail начинает отставать. (данные на нем) Так что просто сменой статуса проблему не решить (возможно что то не знаю) Азус это ASUS, вы часто видели стоечное оборудование от данного бренда ? (вот и вопрос, отсутствие индикации сбойного диска это нормально ?) Я вот тоже подозреваю контроллер, но как это определить вопрос открытый (остается только наблюдать).

Evgeniy39
() автор топика
Последнее исправление: Evgeniy39 (всего исправлений: 1)
Ответ на: комментарий от Evgeniy39

Чтоб нормально вернуть диск он должен быть ресинхронизирован в Рейд, так как он после того как получает статус Fail начинает отставать

Я не про рейдовый статус а про статус физического диска. Ты так и не сказал какая там конкретно была ошибка.

Имелось ввиду такое - из рейда его удаляем, bad меняем на good, добавляем назад в рейд как новый и он ресинхронизируется с нуля.

Азус это ASUS, вы часто видели стоечное оборудование от данного Бренда ?

Ни разу не видел. И вообще на мой взгляд стоит эту фирму избегать (и на десктопах тоже), хотя мне тут некоторые доказывали что она не хуже других.

Я вот тоже подозреваю контроллер но как это определить вопрос открытый

Если есть ещё свободные слоты то насувать туда тестовых дисков, собрать рейд, записать данные, вынуть один диск чтоб зафейлился, записать/переписать данные на массиве, вставить назад диск и добавить в рейд, подождать конца синхронизации (в её время можно тоже грузить массив чтениями или записями), посмотреть что получилось.

firkax ★★★★★
()
Ответ на: комментарий от firkax

К сожалению не записал статус, Fail вроде был, smart с него не читался, но опять же эти данные получены через контроллер, так как диск в него воткнут что логично (вроде правильно ваш вопрос понял), а вот идея с свободными слотами не плоха, с другой стороны если в нем контролер с проблемами, есть шанс захерить все. Данная железка по сути NAS для бэкапов. По поводу удалить его из рейда, я это и сделал, пытался подсветить слот, удалил диск. Но так как не смог определить слот, пустил сервер на перезагрузку, надеясь на графическое меню контролера, там этот диск нашелся как unconfigured bad, SMART OK

Evgeniy39
() автор топика
Последнее исправление: Evgeniy39 (всего исправлений: 4)