| 1.1, Zulu (?), 01:53, 30/06/2010  [ответить]  [↓]     [к модератору] 
 | +/– |  | 
Году в 2007 я тоже перся, найдя все это.
 Только все это не бесплатно: битмапы постоянно стоят кажется около процента скорости, так что надо считать окупится ли это или нет.
 А скорость ребилда так вообще просто увеличивается за счет текущих дисковых операций. 50 мб/сек? да не вопрос, но что у вас станет с собственно задачами, выполняемыми сервером?
   |  |   |   
|   | 
| 2.2, LionSoft (ok), 10:11, 30/06/2010 [^] [^^] [^^^] [ответить]      [к модератору] 
 | +/– |  
 > но что у вас станет с собственно задачами, выполняемыми сервером?
ничего страшного: зависит-же от задачи сервера... Если это backup сервер который работает активно по ночам, то потратить 2 часа днем на перестройку массива можно и на максимальной скорости.
   |  |   |   
 |   
 
 
| 1.3, PavelR (??), 20:42, 30/06/2010  [ответить]  [↑]     [к модератору] 
 | +/– |  
а если он днем не загружен, то перестройка и так будет идти на максимальной для дисков скорости, ну если ограничение speed_limit_max конечно не достигнуто...
  |  |   |   
 
| 1.4, Одмин (?), 01:52, 01/07/2010  [ответить]      [к модератору] 
 | +/– |  
А каким образом подключение битмапа должно ускорить синхронизацию? Чтобы синкалось быстро они должны быть всегда включены а не на этапе ребилда.
  |  |   |   
 
| 1.5, rm_ (ok), 08:52, 01/07/2010  [ответить]  [↓]     [к модератору] 
 | +/– |  
 > Если ресинхронизация производится после развала RAID в результате краха системы, без замены диска, то дополнительно можно использовать режим оптимизации битовых карт
ОМГ какой же махровый бред.
   |  |   |   
|   | 
| 2.6, rm_ (ok), 09:02, 01/07/2010 [^] [^^] [^^^] [ответить]      [к модератору] 
 | +/– |  
 Если же ресинхронизация производилась в результате краха (внеплановой перезагрузки) системы, и вы хотите, чтобы в будущем подобные случаи приводили не к полной, а к частичной (ещё на порядок более быстрой) ресинхронизации, можно включить на массиве режим использования битовой карты намерений записи (write-intent bitmap):
   mdadm --grow --bitmap=internal --bitmap-chunk=131072 /dev/md0
 Использование битовой карты замедляет работу с массивом на запись, однако этот эффект можно уменьшить, использовав достаточно большое значение блока карты (как в примере выше - 131072).
 (об этом и других параметрах см. http://romanrm.ru/mdadm-raid )
   |  |   |   
 |   
 
 
| 1.7, Igor (??), 18:48, 10/02/2011  [ответить]  [↑]     [к модератору] 
 | +/– |  
 Интересное наблюдение:
 при дополнительной загрузке ЦПУ скрорость сборки массива (Уровень 5, 4 SATA диска 500G) увеличивается
 Заметил когда параллельно сборке массива запустил компиляцию.
 Скорость сборки при ненагруженном процессоре 24Mb/sec
 При нагруженном burnP5 - скорость 60Mb/sec
Понять не могу почему.
   |  |   |   
|   | 
| 2.8, rm_ (ok), 18:52, 10/02/2011 [^] [^^] [^^^] [ответить]      [к модератору] 
 | +/– |  
 > Интересное наблюдение: 
 > при дополнительной загрузке ЦПУ скрорость сборки массива (Уровень 5, 4 SATA диска 
 > 500G) увеличивается 
 > Заметил когда параллельно сборке массива запустил компиляцию.
 > Скорость сборки при ненагруженном процессоре 24Mb/sec 
 > При нагруженном burnP5 - скорость 60Mb/sec 
 > Понять не могу почему.
echo performance > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
 дальше догадаетесь или расписывать?
   |  |   |   
|   | 
| 3.9, Igor (??), 19:34, 10/02/2011 [^] [^^] [^^^] [ответить]      [к модератору] 
 | +/– |  
 Догадался, но даже при макс частоте (perfomance) эффект сохраняется.
 Ресурсов процессора на ребилд расходуется 5-10%, не думаю что частота должна как-то сильно (более 2х раз) повлиять на ребилд
  |  |   |   
 |   
 |   
 
 
 
 |