gs писал(а):
Если теоретически, то на современном контроллере (заведомо более быстром, нежели диски), время редилда сводится ко времени перезаливки данных на новый винт (т.е. часов 10 для быстрого шеститонника). Это если без нагрузки.
Ну я бы переформулировал чуть более обстоятельно.
1.
Ребилд сводится к перезаливке данных на новый винт (в нашем случае - данных, вычисляемых из КС и уцелевших блоков стрипов).
2.
Время ребилда зависит от нагрузки.
gs писал(а):
А вот под нагрузкой, опять же теоретически, чем больше винтов, тем меньше влияние боевой нагрузки на увеличение времени ребилда (вызванного нагрузкой).
Вообще я бы предложил вначале рассмотреть массив "в статике", без нагрузки.
Теоретически при ребилде считываются (одновременно(?) с каждого(?) диска рейд-группы) все дата-блоки одного стрипа и вкупе с КС из них получаем недостающие дата-блоки этого стрипа, которые и записываем на чистый диск (HSD).
Соответственно, пока мы не упёрлись в производительность контроллера - пока он успевает обсчитывать ВСЕ дата-блоки с, скажем 7-ми дисков (из деградировавшего 8-мидискового массива) и писАть вычисленное на HSD - добавление новых дисков в рейд-группу приведёт,
по идее, к увеличению скорости ребилда.
Тогда если мы на, допустим, 12 дисках упрёмся в вычислительные возможности контроллера, то повышать далее к-во дисков в группе смысла не будет.
Наличие любого процента нагрузки в этой картине по большому счёту ничего не меняет - просто "на вход" процесса вычисления недостающих дата-блоков будет этих самых блоков поступать пропорционально меньше.
Хотя-а-аааа... Может, тут-то и порылась енотовидная собака? Ну типа чем больше будет дисков в рейд-группе, тем пропорционально больше будет попадать данных "на вход" ребилда и, соответственно, "вычислитель" будет "наедаться" позже??? Т.е. формально Вы можете оказаться правы в своём предположении.
Но это как-то не очень вяжется с практикой, когда большие массивы ребилдятся неделями.
Ой как лениво стенд собирать...
Угу. Собственно, не в последнюю очередь и из-за этого я озадачился. Хочется лучше понимать происходящее с - прежде чем "собирать стенд"... или боевую хранилку.
К слову, вопрос ни разу не теоретический, а в рамках выбора - делать R6 или кроить R60 ???
Второй "статистически надёжнее", но выходит так, что сабъюнит R60-го будет ребилдиться медленнее, чем R6 размером с весь R60-й - просто по факту разного кол-ва дисков?
UPD: Остаётся выяснить - видимо, только опытным путём - оптимальное (максимальное) для конкретного контролера кол-во дисков для рейд-группы с чётностью и плясать уже от этого.
Полагаю, можно для эмпирической увязки (а конкретно - бенчмарку процесса ребилда) использовать набор SSD - и делать выводы из того их кол-ва, на котором скорость ребилда (ес-сно, без нагрузки), перестанет возрастать.
UPD2: Вдогонку вдруг посетила мысль - а не слишком ли я загоняюсь по этому делу?
Ведь даже если чип контроллера молотит как не в себя, то запись вычисленного-то всё равно идёт на ОДИН диск.
Получается, что при любом раскладе контроллер может получать "на вход" ребилда любое возможное кол-во данных (дата-блоки + КС), но ограничением будет скорость линейной записи на один диск?
UPD3: Только что заметил - мой UPD2 практически повторяет Ваш ответ в части фразы, начинающейся с "Если теоретически...".
М-да, недосып фатально влияет на внимательность...
