Bug 11511

Summary: restrict max raid sync speed during installation
Product: Sisyphus Reporter: Michael Shigorin <mike>
Component: alterator-install2Assignee: Dmitry V. Levin <ldv>
Status: CLOSED FIXED QA Contact: qa-sisyphus
Severity: critical    
Priority: P2 CC: lakostis, ldv, legion, vsu
Version: unstable   
Hardware: all   
OS: Linux   
Bug Depends on:    
Bug Blocks: 9199    

Description Michael Shigorin 2007-04-15 17:00:53 MSD 
Предлагается ограничить скорость синхронизации 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 Dmitry V. Levin 2007-04-29 01:06:21 MSD 
К сожалению, при создании новых raid'ов alterator-vm'ом переход в консоль
для того, чтобы снизить скорость синхронизации, сейчас является 
необходимым условием завершения установки системы в разумное время.

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

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

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

недосинканный raid1 вполне принял lilo в mbr'ы и досинкался при загрузке =>
что-то смущавшее меня скорее всего неважно.
Comment 10 Dmitry V. Levin 2007-05-01 19:06:50 MSD 
На installer.
Comment 11 Michael Shigorin 2007-05-02 08:04:57 MSD 
(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 Dmitry V. Levin 2007-05-04 04:38:20 MSD 
Проверил в двух вариантах:
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 Michael Shigorin 2007-11-10 18:34:52 MSK 
Надо будет отдельно проверить...
Comment 14 Dmitry V. Levin 2008-01-26 01:27:30 MSK 
(In reply to comment #13)
> Надо будет отдельно проверить...

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