Предлагается ограничить скорость синхронизации 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 пошёл на другое зеркало на тех же двух дисках.
К сожалению, при создании новых raid'ов alterator-vm'ом переход в консоль для того, чтобы снизить скорость синхронизации, сейчас является необходимым условием завершения установки системы в разумное время. Поэтому повышаю severity.
в alterator-vm нет места для манипуляций подобного рода.
Я бы ограничился каким-нибудь хаком в alterator-install2 сразу после alterator-vm, если бы не тормоза при форматировании тома, размещённого на свежесозданном raid'е.
предлагаю такое определение проблемы: - в фазе коммита запрошенных изменений (которая для вызывающей стороны атомарна) следует выделять последовательность создание рэйда + создание файловой системы на нём, между первым и вторым действием необходимо ограничить скорость синхронизации рэйда до минимальной величины. вопросы: 1) это покрывает все варианты ? 2) следует ли возвращать скорость синхронизации до максимальной после mkfs ?
Поверх созданного raid'а можно сделать не только целую файловую систему, но и что-нибудь менее тривильное, например, lvm. Вероятно, имеет смысл ограничивать скорость синхронизации raid'а в любом случае, поскольку синхронизация тормозит все операции с вовлеченным диском, даже если области диска не пересекаются.
(In reply to comment #4) > 2) следует ли возвращать скорость синхронизации до максимальной после mkfs ? Для корня -- да, для остального -- нет. Если несколько md собраны из блокдевайсов имени devmapper, то md не умеет откладывать синхронизацию тех, которые на одних физических дисках. С дефолтным cfg iosched это звучит (и длится) ужасающе.
mike@ предлагает ограничиться echo 100 >/proc/sys/dev/raid/speed_limit_max Если это работает правильно, то в evms делать ничего не надо.
ок, я жду подтверждения.
чего/чьего? недосинканный raid1 вполне принял lilo в mbr'ы и досинкался при загрузке => что-то смущавшее меня скорее всего неважно.
На installer.
(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 границу по секторам, сильно жалея, что этого не сделал инсталер).
Проверил в двух вариантах: 1. новые raid1 и raid5, созданные в /vm 2. недосинхонизированный raid5, подхваченный в /vm В обоих вариантах скорость синхронизации не поднималась выше 5% над опущенным значением /proc/sys/dev/raid/speed_limit_max. Fixed in alterator-install2-0.8.4-alt1
Надо будет отдельно проверить...
(In reply to comment #13) > Надо будет отдельно проверить... Я уже столько раз проверил, что можно закрыть.
