Как ускорить миграцию с рейда 5 на рейд 6 с помощью mdadm?

Сегодня я начал миграцию своего рейда 5 в Raid 6, добавив новый диск (от 7 до 8 дисков, все 3 ТБ). Теперь выполняется изменение:

Personalities : [raid6] [raid5] [raid4] md0 : active raid6 sdi[9] sdh[8] sdf[7] sdc[6] sdd[4] sda[0] sde[5] sdb[1] 17581590528 blocks super 1.2 level 6, 512k chunk, algorithm 18 [8/7] [UUUUUUU_] [>....................] reshape = 2.3% (69393920/2930265088) finish=6697.7min speed=7118K/sec unused devices: <none> 

но это медленно, как черт. Это будет почти за 5 дней до завершения. Я использовал для изменения массива примерно через 1 день, но здесь это ужасно. Скорость очень низкая. Файл резервной копии находится на SSD.

Я изменил размер полосы и минимальные и максимальные ограничения скорости, и это ничего не изменило.

Есть ли способ ускорить процесс до разумного количества времени, или мне нужно подождать 5 дней?

Обновление: iostat -kx 10

 avg-cpu: %user %nice %system %iowait %steal %idle 0.05 0.00 1.68 22.07 0.00 76.20 Device: rrqm/s wrqm/sr/sw/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 1675.90 1723.00 27.60 23.90 13875.20 6970.00 809.52 0.55 10.79 8.59 13.33 7.97 41.02 sdb 1675.90 1723.10 27.20 23.80 13670.40 6970.00 809.43 0.55 10.80 8.96 12.90 8.12 41.43 sdc 1675.90 1723.60 27.50 23.30 13824.00 6970.00 818.66 0.65 12.85 10.48 15.65 9.83 49.94 sdd 1675.90 1723.10 27.60 23.80 13875.20 6970.00 811.10 0.55 10.80 8.93 12.98 8.16 41.95 sde 1675.90 1723.10 27.20 23.80 13670.40 6970.00 809.43 0.60 11.79 9.17 14.79 9.19 46.87 sdf 1675.90 1723.80 27.70 23.10 13926.40 6970.00 822.69 0.72 14.28 11.65 17.43 10.12 51.40 sdg 0.00 4.10 0.00 93.20 0.00 39391.20 845.30 6.07 65.14 0.00 65.14 2.71 25.29 dm-0 0.00 0.00 0.00 4.30 0.00 18.40 8.56 0.00 0.07 0.00 0.07 0.02 0.01 dm-1 0.00 0.00 0.00 89.60 0.00 39372.80 878.86 6.07 67.78 0.00 67.78 2.82 25.28 md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdh 1583.50 1631.70 216.50 115.90 13824.00 6970.00 125.11 1.56 4.73 5.36 3.55 0.43 14.41 sdi 0.00 1631.70 0.00 115.90 0.00 6970.00 120.28 0.21 1.77 0.00 1.77 0.28 3.25 dm-2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 

sdi – это последний диск, который я добавил. sdg – SSD. DmX – это разделы на LVM.

  • Ошибка MDADM RAID 0
  • Метаданные mdadm: следует ли принимать меры предосторожности для предотвращения перезаписи суперблока?
  • Новый массив md является автоматическим чтением и имеет resync = PENDING
  • Почему прошивка uEFI не может получить доступ к файлу RAID 1 / boot / efi?
  • Как собрать конкретный массив RAID без использования /etc/mdadm.conf
  • CentOS 7 создал mdadm-массив после перезагрузки
  • mdadm - исключить из монитора
  • Правильный способ настройки RAID в Linux
  • 2 Solutions collect form web for “Как ускорить миграцию с рейда 5 на рейд 6 с помощью mdadm?”

    Мне кажется, что это связано с миграцией mdadm из рейда 5 в рейд 6. Я только что добавил новый диск в массив, и скорость роста вполне разумна (40000 К / с) для моего оборудования.

    Согласно этому сообщению блога Нилом Брауном ( создателем mdadm ), вы можете избежать штрафа за скорость из-за процесса резервного копирования блока диапазона mdadm :

    1. Увеличение количества RAID-устройств (например: переформатирование с 4-дискового RAID5 на 5-дисковый RAID6) mdadm --grow /dev/md0 --level=6 --raid-disk=5
    2. Не указывайте опцию --backup-file

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

    Этот отрывок из его статьи объясняет это более подробно:

    Как работает изменение уровня

    Если мы подумаем о «RAID5» как о более общем, чем стандартное определение, и позвольте ему быть любым макетом, который разбивает данные на 1 блок четности на несколько устройств, тогда мы можем думать о RAID4 как о простом случае RAID5 , Затем мы можем представить себе преобразование из RAID0 в RAID5 как взятие двух шагов. Первый конвертирует в RAID5 с использованием макета RAID4 с диском четности в качестве последнего диска. Это явно не требует, чтобы данные были перемещены, поэтому изменение может быть мгновенным. Он создает ухудшенный RAID5 в макете RAID4, поэтому он не является полным, но это явно шаг в правильном направлении. Я уверен, вы можете видеть, что будет дальше. После преобразования RAID0 в деградированный RAID5 с необычным макетом мы использовали бы новую функциональность change-the-layout для преобразования в настоящий RAID5.

    Это очень похожий процесс, который теперь можно использовать для преобразования RAID5 в RAID6. Сначала мы изменим RAID5 на RAID6 с нестандартной компоновкой, в которой блоки четности распределены как обычно, но Q блокирует все на последнем устройстве (новое устройство). Так что это RAID6 с использованием драйвера RAID6, но с макетом, отличным от RAID6. Поэтому мы «просто» меняем макет и выполняем работу.

    RAID6 можно преобразовать в RAID5 с помощью обратного процесса. Сначала мы меняем макет на макет, который почти RAID5, но с дополнительным Q-диском. Затем мы переходим к реальному RAID5, забывая о Q-диске.

    Сложности данных повторной чередования

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

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

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

    Это самая сложная часть новой функциональности в mdadm 3.1 (которая еще не выпущена, но ее можно найти в ветке devel-3.1 для git: //neil.brown.name/mdadm). mdadm контролирует изменение, устанавливая верхнюю границу того, как далеко он может прогрессировать в любое время, и убедитесь, что область, которую он позволяет переупорядочить, отключена и была скопирована.

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

    Linux и Unix - лучшая ОС в мире.