11511 2007-04-15 17:00:53 +0400 restrict max raid sync speed during installation 2008-01-26 01:27:30 +0300 1 1 4 Development Sisyphus alterator-install2 unstable all Linux CLOSED FIXED P2 critical --- 9199 1 mike ldv lakostis ldv legion vsu qa-sisyphus oldest_to_newest 48852 0 mike 2007-04-15 17:00:53 +0400 Предлагается ограничить скорость синхронизации 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 пошёл на другое зеркало на тех же двух дисках. 49651 1 ldv 2007-04-29 01:06:21 +0400 К сожалению, при создании новых raid'ов alterator-vm'ом переход в консоль для того, чтобы снизить скорость синхронизации, сейчас является необходимым условием завершения установки системы в разумное время. Поэтому повышаю severity. 49653 2 sbolshakov 2007-04-29 02:09:04 +0400 в alterator-vm нет места для манипуляций подобного рода. 49654 3 ldv 2007-04-29 02:16:28 +0400 Я бы ограничился каким-нибудь хаком в alterator-install2 сразу после alterator-vm, если бы не тормоза при форматировании тома, размещённого на свежесозданном raid'е. 49655 4 sbolshakov 2007-04-29 02:17:16 +0400 предлагаю такое определение проблемы: - в фазе коммита запрошенных изменений (которая для вызывающей стороны атомарна) следует выделять последовательность создание рэйда + создание файловой системы на нём, между первым и вторым действием необходимо ограничить скорость синхронизации рэйда до минимальной величины. вопросы: 1) это покрывает все варианты ? 2) следует ли возвращать скорость синхронизации до максимальной после mkfs ? 49656 5 ldv 2007-04-29 02:36:08 +0400 Поверх созданного raid'а можно сделать не только целую файловую систему, но и что-нибудь менее тривильное, например, lvm. Вероятно, имеет смысл ограничивать скорость синхронизации raid'а в любом случае, поскольку синхронизация тормозит все операции с вовлеченным диском, даже если области диска не пересекаются. 49688 6 mike 2007-04-30 03:13:37 +0400 (In reply to comment #4) > 2) следует ли возвращать скорость синхронизации до максимальной после mkfs ? Для корня -- да, для остального -- нет. Если несколько md собраны из блокдевайсов имени devmapper, то md не умеет откладывать синхронизацию тех, которые на одних физических дисках. С дефолтным cfg iosched это звучит (и длится) ужасающе. 49697 7 ldv 2007-04-30 14:47:00 +0400 mike@ предлагает ограничиться echo 100 >/proc/sys/dev/raid/speed_limit_max Если это работает правильно, то в evms делать ничего не надо. 49700 8 sbolshakov 2007-04-30 16:12:42 +0400 ок, я жду подтверждения. 49730 9 mike 2007-05-01 18:14:52 +0400 чего/чьего? недосинканный raid1 вполне принял lilo в mbr'ы и досинкался при загрузке => что-то смущавшее меня скорее всего неважно. 49734 10 ldv 2007-05-01 19:06:50 +0400 На installer. 49760 11 mike 2007-05-02 08:04:57 +0400 (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 границу по секторам, сильно жалея, что этого не сделал инсталер). 49823 12 ldv 2007-05-04 04:38:20 +0400 Проверил в двух вариантах: 1. новые raid1 и raid5, созданные в /vm 2. недосинхонизированный raid5, подхваченный в /vm В обоих вариантах скорость синхронизации не поднималась выше 5% над опущенным значением /proc/sys/dev/raid/speed_limit_max. Fixed in alterator-install2-0.8.4-alt1 57893 13 mike 2007-11-10 18:34:52 +0300 Надо будет отдельно проверить... 61990 14 ldv 2008-01-26 01:27:30 +0300 (In reply to comment #13) > Надо будет отдельно проверить... Я уже столько раз проверил, что можно закрыть.