Назад | Перейти на главную страницу

Когда Raid восстанавливает избыточность после того, как сломанный сектор помечен как дефектный?

Что произойдет, если я помечу сектор на жестком диске в настройке RAID как «неисправный (GLIST)»?

Будут ли данные записываться в замещающий сектор сразу или это зависит от фактических настроек / настроек (программный / аппаратный рейд)?

Пример: Raid 5 - 4 диска - Linux Hardware Raid

На HDD 1 обрывается сектор 0x123456. Он помечен как неисправный. Это приводит к тому, что данные в этом секторе помечаются как потерянные, и теперь сектор будет указывать на данные конкретного поставщика. Но поскольку рейд содержит 1 копию, действительные данные могут быть восстановлены.

В какой момент данные на сломанном диске будут восстановлены, таким образом, снова будут иметь 2 набора действительных данных?

Я полагаю, что это будет один из них:

Если это действительно индивидуальная проблема / настройка, меня особенно заинтересует Smart Array P800.

Но, пожалуйста, поделитесь всем, что вам известно об этом.

PS: Если вы нашли это в Google, сайт smartmontools - отличная отправная точка: например, http://smartmontools.sourceforge.net/badblockhowto.html#bb

Смотря как.

В повседневной работе ваш жесткий диск записывает контрольную сумму и некоторую информацию ECC для каждого записываемого сектора и проверяет эти данные во время операции чтения.

Если ошибка достаточно мала (например, перевернутый бит или другие незначительные ошибки), чтобы ее можно было охватить возможностями ECC вашего жесткого диска, ваш жесткий диск может исправить это самостоятельно. Исправленная ошибка все еще может быть видна в выходных данных SMART, но операционная система или аппаратный RAID-контроллер не заметили ошибку чтения.

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

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

Аппаратные RAID-контроллеры обычно пытаются обнаружить такие отказавшие секторы «раньше», чем обычный доступ для чтения, выполняя фоновое сканирование носителя, запланированные самотестирование и проверяя точность сохраненной четности рейда.

Если ошибка исправляется путем перезаписи того же самого сектора - это совсем другое дело, эта область в значительной степени недокументирована и в основном зависит от личного опыта. Исходя из моего 15-летнего опыта работы на десятках тысяч серверов, на которых установлены десятки аппаратных RAID-контроллеров от полдюжины различных поставщиков:

  • некоторые поставщики всегда выполняют фоновое сканирование носителей и пытаются автоматически исправить плохие блоки. HP / Compaq находится на этой стороне.
  • некоторые поставщики делают постоянное фоновое сканирование носителей опцией, которая должна быть специально включена (и по умолчанию она отключена после включения).
  • некоторые поставщики предлагают фоновое сканирование мультимедиа как разовую операцию, которая должна запускаться вручную через интерфейс администратора или CLI.
  • некоторые поставщики ломают даже больше.

В качестве примера для «сломать еще больше», около 10 лет назад у меня были серьезные проблемы в конфигурации RAID 10 на конкретном типе контроллера: иногда были повреждены файловая система и данные приложений. Более тщательное исследование и введение контрольной суммы на уровне приложений показали, что иногда считывались нули, но ожидались ненулевые данные.

Виновник: при чтении из плохого блока контроллер зарегистрировал это как ошибку, но не восстановился из рабочей копии вообще. Вместо этого он сообщил, что окружающая полоса данных размером 8 Кбайт представляет собой полосу нулей, и операция чтения была успешной. Поведение было воспроизведено на> 100 контроллерах, и служба поддержки поставщика даже заявила, что это вполне приемлемо, поскольку RAID должен был восстанавливаться только после полного отказа диска, а не обрабатывать отказ отдельных блоков.

В конфигурации RAID4 / RAID5 тот же самый контроллер восстановит избыточность RAID и доставит восстановленную полосу в ОС, но не будет автоматически восстанавливать сбойный блок на диске. Для восстановления после сбойного блока нужно было либо перезаписать тот же логический блок на уровне ОС, либо выполнить операцию «регенерации четности» в интерфейсе администратора. Последний будет сканировать все диски, проверять контрольные суммы четности RAID и пытаться восстановить плохие блоки, перезаписывая любые блоки с ошибкой чтения или неудачной проверкой четности RAID.

С другой стороны, Compaq / HP уже много лет выполняют фоновое сканирование своих RAID-контроллеров, и если блок / сектор не может быть автоматически восстановлен из четности или что-то еще выглядит подозрительно, контроллер регистрирует это, начинает мигать светодиоды. поврежденных дисков и попытайтесь предупредить администратора (например, с помощью экрана сообщения во время POST). Я не слышал о каких-либо проблемах с плохими блоками в нашем текущем парке, насчитывающем около 10 тысяч контроллеров HP Smart Array, включая около 1100 P800. Однако это только мой опыт.