Bug 11511 - restrict max raid sync speed during installation
: restrict max raid sync speed during installation
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/alterator-install2)
: unstable
: all Linux
: P2 critical
Assigned To:
:
:
:
:
: 9199
  Show dependency tree
 
Reported: 2007-04-15 17:00 by
Modified: 2008-01-26 01:27 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2007-04-15 17:00:53
Предлагается ограничить скорость синхронизации MD RAID после их запуска и на
время установки -- возможно, всем, кроме корневого (если назначен), бо при
разваленном [_U] lilo не встало.

(это /sys/block/md*/md/sync_speed_max -- min тоже лучше зарубить)

<gvy> выловил ещё одну неприятную особенность, если md поднимается evms на dm-*
<gvy> райды на одних шпинделях синхронизируются одновременно ;(
<gvy> vsu, а на это однострочного патчика ж не бывает? :)
<gvy> и ведь нечем даже остановить пустой здоровый raid1 в инсталере :-/
<gvy> переключил в deadline -- судя по звуку, помогло (сикает заметно меньше)
<vsu> gvy: echo -n idle >/sys/block/mdX/md/sync_action
<gvy> какая благодатная почва для вагона AI в инсталере... "если райды -- такой
скедулер, если нет -- сякой" :)
<gvy> vsu, ух ты, спасибо
<vsu> gvy: потом туда же resync - вроде так
<gvy> vsu, ignored
<vsu> gvy: ну вообще я это не проверял...
<gvy> в смысле там resync и остаётся. :)
<vsu> gvy: а в /proc/mdstat?
<gvy> vsu, бежит как милый
<gvy> сделал ему 100 > sync_speed_ max
<gvy> м-да, а ведь это грабли devmapper <-> md, получается
<gvy> о, придумал
<gvy> надо на ремя установки делать sync_speed_max=100 всем и баиньки
<vsu> gvy: если однострочный патч - только отключить параллельный resync вообще
<gvy> vsu, я уже пошёл повесить багу на /vm -- собсно в AW так и делалось вроде

Вешаю #9199 blocker, поскольку до переключения (в
/sys/block/sd*/queue/scheduler) iosched с cfq на deadline треск от дисков шёл
изрядный...

PS:

<vsu> gvy: вообще странно, что idle не сработало
<vsu> gvy: вроде бы прерывание там как раз предусмотрено
<gvy> vsu, ну как есть
<gvy> vsu, -n было лишнее :-)
<vsu> gvy: но на echo оно не выругалось?
<gvy> vsu, не, оно и тогда не ругалось; и содержимое осталось resync, но
движняк
соскочил на другой параллельный массив

бишь echo idle > /sys/block/md2/md/sync_action перевело md2 в DELAYED и resync
пошёл на другое зеркало на тех же двух дисках.
------- Comment #1 From 2007-04-29 01:06:21 -------
К сожалению, при создании новых raid'ов alterator-vm'ом переход в консоль
для того, чтобы снизить скорость синхронизации, сейчас является 
необходимым условием завершения установки системы в разумное время.

Поэтому повышаю severity.
------- Comment #2 From 2007-04-29 02:09:04 -------
в alterator-vm нет места для манипуляций подобного рода.
------- Comment #3 From 2007-04-29 02:16:28 -------
Я бы ограничился каким-нибудь хаком в alterator-install2 сразу после
alterator-vm, если бы не тормоза при форматировании тома, размещённого на
свежесозданном raid'е.
------- Comment #4 From 2007-04-29 02:17:16 -------
предлагаю такое определение проблемы:
- в фазе коммита запрошенных изменений (которая для вызывающей стороны 
атомарна) следует выделять последовательность создание рэйда + создание 
файловой системы на нём, между первым и вторым действием необходимо
ограничить скорость синхронизации рэйда до минимальной величины.
вопросы: 
1) это покрывает все варианты ? 
2) следует ли возвращать скорость синхронизации до максимальной после mkfs ?
------- Comment #5 From 2007-04-29 02:36:08 -------
Поверх созданного raid'а можно сделать не только целую файловую систему, но и
что-нибудь менее тривильное, например, lvm.  Вероятно, имеет смысл ограничивать
скорость синхронизации raid'а в любом случае, поскольку синхронизация тормозит
все операции с вовлеченным диском, даже если области диска не пересекаются.
------- Comment #6 From 2007-04-30 03:13:37 -------
(In reply to comment #4)
> 2) следует ли возвращать скорость синхронизации до максимальной после mkfs ?
Для корня -- да, для остального -- нет.

Если несколько md собраны из блокдевайсов имени devmapper, то md не умеет
откладывать синхронизацию тех, которые на одних физических дисках.  С дефолтным
cfg iosched это звучит (и длится) ужасающе.
------- Comment #7 From 2007-04-30 14:47:00 -------
mike@ предлагает ограничиться
echo 100 >/proc/sys/dev/raid/speed_limit_max

Если это работает правильно, то в evms делать ничего не надо.
------- Comment #8 From 2007-04-30 16:12:42 -------
ок, я жду подтверждения.
------- Comment #9 From 2007-05-01 18:14:52 -------
чего/чьего?

недосинканный raid1 вполне принял lilo в mbr'ы и досинкался при загрузке =>
что-то смущавшее меня скорее всего неважно.
------- Comment #10 From 2007-05-01 19:06:50 -------
На installer.
------- Comment #11 From 2007-05-02 08:04:57 -------
(In reply to comment #7)
> mike@ предлагает ограничиться
> echo 100 >/proc/sys/dev/raid/speed_limit_max
> Если это работает правильно, то в evms делать ничего не надо.
Зараза, уже не уверен: после такого в /sys/block/md?/md/sync_speed_max
наблюдалось "200000 (local)".  Возможно, значение инициализируется из
/proc/sys/dev/raid/speed_limit_max при сборке массива -- сейчас уже не настолько
свежая голова, чтобы спокойно поставить эксперимент (выравнивал 900-гиговый
raid5 на кратную stripe size границу по секторам, сильно жалея, что этого не
сделал инсталер).
------- Comment #12 From 2007-05-04 04:38:20 -------
Проверил в двух вариантах:
1. новые raid1 и raid5, созданные в /vm
2. недосинхонизированный raid5, подхваченный в /vm
В обоих вариантах скорость синхронизации не поднималась выше 5% над опущенным
значением /proc/sys/dev/raid/speed_limit_max.

Fixed in alterator-install2-0.8.4-alt1
------- Comment #13 From 2007-11-10 18:34:52 -------
Надо будет отдельно проверить...
------- Comment #14 From 2008-01-26 01:27:30 -------
(In reply to comment #13)
> Надо будет отдельно проверить...

Я уже столько раз проверил, что можно закрыть.