Так, мне кажется у вас каша. Давайте разберемся.
1) Параметр ERC влияет только на скорость негативного ответа от
жесткого диска в случае проблем. Ерк - 0, то работают внутренние
таймауты диска, обычно достаточно длинные. Ерк выставлен - диск просто
даст негативных ответ сразу после таймаутов.
2) Если рейд не смог записать что-то на диск - его правильная реакция
- попытаться повторить запись несколько раз и выкинуть сбойный винт из
массива. Никаким "ремонтом" он заниматься не может и не должен. С
чтением - возможны варианты, но я не уверен что кто-то пытается
перезаписывать сбойный сектор по чтению, скорее всего реакция будет
такая же. Единственное что может помочь - при выставленном ерк рейд
сделает не 1 попытку, а больше, так как таймеры не сработают, и винт
таки сделает ремап. Но это только на записи поможет
3) В итоге - если винт глючный - рейд выкинет его как с ерк=0, так и с
ерк=100 (10 секунд), но во втором случае это произойдет намного
раньше. Кроме того - наша система не будет ужасно тупить пытаясь
получить ответ от умирающего лиска.
4) Если у вас начинаются задержки по чтению-записи такие, что рейд
выкидывает диск - ему прямая дорого в рма, и в смарте это должно быть
очень хорошо видно.
5) С хардварными рейдами можно наступить еще и на глюки прошивки,
которые вообще не имеют никакого отношение к обсуждаемой теме.
Даже не знаю как "возразить"... И у кого каша...
Давайте же разберемся... В рамках данной переписки обсуждается работа:
1. Исправного RAID контроллера
2. Исправных жестких дисков
3. Построение аппаратных массивов на базе Desktop (Err Ctl > 8 sec) и RE
(Err Ctl меньше или равно 7 сек)
Немного теории о контроллерах:
*Disk Failure Detection (Обнаружение неисправности дисководов)* - RAID
контроллер может автоматически обнаруживать повреждения SCSI дисководов.
Процесс контроля основывается, среди прочего, на анализе времени
выполнения команд, посланных дисководу. Если дисковод в течении
определенного времени не подтверждает выполнение команды, контроллер
осуществляет "сброс" дисковода и посылает команду повторно. Если команда
снова не выполняется за заданное время, дисковод может быть контроллером
отключен (установлен в режим "offline") и его состояние фиксируется, как
"dead" ("мертвый"). Многие RAID контроллеры также контролируют ошибки
четности SCSI шины и другие потенциальные проблемы.
*Disk Media Error Management (Система Обработки Ошибок Дисководов)* -
RAID контроллеры способны обрабатывать ошибки внутреннего кэша и SCSI
дисководов. Если установлен кэш с ECC, контроллер исправит одиночные и
зафиксирует двойные ошибки. Дисководы могут быть запрограммированы так,
чтобы сообщать об ошибках, даже если это восстанавливаемые ошибки. Когда
дисковод сообщает об ошибке во время чтения, контроллер считывает
соответствующие данные из зеркального дисковода (RAID 1 или 0+1), или
восстанавливает данные, используя информацию, хранящуюся в других блоках
(RAID 3, RAID 5), и записывает данные назад на тот дисковод, который
столкнулся с ошибкой. Если произошел сбой при записи, контроллер
пропускает тот блок, в котором возникла ошибка, и затем записывает
данные в следующий блок. Если проблема была успешно решена, то никакие
сообщения об ошибках в систему не передаются.
Теперь о поведении Desktop диска в массиве:
Если происходит ошибка чтения или записи на ИСПРАВНЫЙ диск - он пытается
ее исправить. Это может занять более 8 секунд.
В данном случае RAID выполняет *Disk Failure Detection (Обнаружение
неисправности дисководов)* и "выбрасывает" исправный диск из массива.
Подобная ситуация НЕ происходит если используются RE диски т.к.
контроллер выполняет *Disk Media Error Management (Система Обработки
Ошибок Дисководов)*, а вот *Disk Failure Detection (Обнаружение
неисправности дисководов)* происходит для дисков, которые можно смело
сдавать по гарантии.
Теперь почему я "приплел" софтовый" райд...
В софтовом массиве работой с дисками занимается ОС, которая может ждать
до 2мин пока диск самостоятельно не исправит ошибку, и потом либо
зависнет либо выкинет его из массива (в данном случае диск так же можно
нести "сдавать")
