Привет.
Еще раз (и последний, чтобы закрыть тему) рассказываю печальную историю
о том как работают рейды. Для Вашего образования.
Давайте для примера остановимся на рейд1 - это самое простое. И так,
если у нас сата или ide диски (у них общий command set) то вся
информация дублируется на два носителя. В sata/ide дисках есть смарт для
отображения состояния и диагностики и есть скрытая зона ремапов, которая
используется диском для замены убитых участков. Важный момент -
менеджмент этой зоны ремапов - дело только прошивки, контроллер об этом
вообще понятия не имеет.
Дальше, никаких "списков плохих секторов" у обычных рейдов нет. Ни
софтварных ни хардварных. Всё, что может сделать рейд если у него
возникла ошибка - это попытаться повторить операцию еще раз. Если и это
не удалось - он отдаст пользователю данные с живого диска и будет
пытаться получить данные еще несколько раз. В случае проблем - просто
пометит диск как сбойный, а массив как degraded. Верный признак такой
беды - это параметр Current_Pending_Sector. Вы можете сделать что-то
вроде dd if=/dev/zero of=/dev/ada0 bs=1M для того, чтобы забить его 0 и
таким образом винт активизирует зону ремапов и будет пользоваться ей
(это очень хорошо видно на графиках raw read). Когда зона ремапов
закончится, то и запись перестанет работать. Вот и все дефект листы.
Идём дальше. Логика SCT таймаутов неплохо описана в стандарте. Немного
цитат:
8.3.3 Error Recovery Control command
The Error Recovery Control command is used to set time limits for read
and write error recovery. For nonqueued
commands, these timers apply to command completion at the host
interface. For queued
commands where in-order data delivery is enabled, these timers begin
counting when the device begins to
execute the command, not when the command is sent to the device. These
timers do not apply to streaming
commands or to queued commands when out-of-order data delivery is
enabled. Time limits for error
recovery may be used in a data redundant RAID environment where it is
more desirable *to have the device
report a data error rather than risk having it being dropped from the RAID*.
Выделение моё.
Вот о том как это работает
If the Read Command Timer is going to expire while the device is
performing error recovery, the device shall
stop processing the command and report an uncorrectable ECC error for
the LBA that was causing error
recovery to be invoked prior to timer expiration. Note that the LBA
might be recoverable given more time for
error recovery. At this point the host may reconstruct the data for the
failing LBA from the other devices in a
RAID and issue a write command to the target LBA, allowing the device to
attempt vendor specific error
recovery on the suspect LBA
The Write Command Timer sets the upper limit for the amount of time a
device processes a write command.
The minimum value for this command is one. Setting this value to zero
shall disable Write Command timeout,
allowing the device to perform all available error recovery procedures
without a time limit.
The Write Command Timer has the effect of controlling how aggressively
the device reallocates write data
when encountering write errors. A large Write Command Timer value allows
the device to use more
available error recovery procedures for dealing with write errors. A
small Write Command Timer value forces
the device to attempt to reallocate sectors that may have otherwise been
written without error. If the timer is
about to expire, then the device should attempt to reallocate the data
before the timer expires. If the device
is unable to complete data reallocation before the timer expires then
the devices fails the command when the
timer expires. When write cache is enabled the operation of the timer is
vendor specific.
Таким образом при записи устройство скорее сделает ремап, а не будет
уходить в себя. Как следствие - если таймаут сделать слишком маленьким -
зона ремапов закончится быстрее.
При этом никаких "волшебных пузырьков" в виде умного рейда запоминающего
плохие сектора и чинящего диски у нас нет. Хотите убедиться - да просто
вытащите 2 диска из рейд1 аппаратного и сравните их побайтово -
отличается только зона для служебной информации контроллера, если она
есть. Есть куча утилит для того, чтобы "собрать" аппаратные рейды
программно (используются когда контроллер говорит "всё"). В скази и сас
есть дефект листы винта и вообще всё несколько сложнее, но мы сейчас не
о них.
Резюмируя:
1) В софтрейдах и хардрейдах оно будет рабоать одинаково, и ничего
такого особенного хардрейд не делает. Так что не надо говорить ерунду,
что это только для хардрейдов.
2) Выставление таймаута на запись и в самом деле уменьшает риск
выпадения диска из рейда при проблемах записи. Но в целом - несильно,
так как ремапы обычно быстро проходят и с отключенным таймаутом.
3) Таймаут на чтение на это не влияет, так как диск всё равно будет
выброшен из массива при достижении некоторого количества попыток (могу
показать вам логи с 3вари или с lsi, их у меня ОЧЕНЬ много).
4) На большинстве винтов scterc можно поменять. В том числе и
десктопных. На многих server edition он по умолчанию выставлен в 8-10
секунд. И, кстати, прекрасно отключается, так как в случае не-рейд
применения это фича скорее вредная (пусть лучше попыхтит 5 минут, но
достанет сбойный сектор).
5) Никаких дефект листов для ата дисков рейд контроллер не ведёт и не
использует. И логика его работы практически ничем не отличается от
mdraid/gmirror. И формат данных на дисках для RAID1/RAID10 обычно крайне
просто понять.
