[Comm] Re:

ASA =?iso-8859-1?q?llb_=CE=C1_udm=2Eru?=
Пт Май 9 10:39:59 MSD 2003


Hello Denis,

Friday, May 9, 2003, 4:12:57 AM, you wrote:

>> Вы только что описали систему поднятия сервисов в WinNT/2000/XP ;)
DS> :)

>> DS> Необязательные -- только обеспечивают соблюдение очерёдности.
>> А  это  хорошая  идея.  Относительно.  Но очередность уже есть в
>> SysV.

DS> В SyV она тольно последовательная. Я имею в виду что-то вроде "почтовый
DS> сервер должен запускать после антивирусного сервиса, если таковой
DS> имеется".
Как мы отметили ниже, такое можно реализовать без потери
совместимости с SysV.

DS> Соответственно последовательность работы загрузчика следующая -- берётся
DS> список поднимаемый сервисов, строится дерево зависимостей, дальше
DS> запускаем скрипты инициализации для N сервисов, из тех, которые можно
DS> инициализировать сразу. После завершения каждого из скриптов смотрим что
DS> следующее можно инициализировать.

Я  протестую  против  "все  враз".  Если запустить слишком много
программ, то они в сумме отработают медленее, чем в сумме каждая
по    отдельности,    из-за    слишком    большого    количества
разноупорядоченных  обращений  к  диску  (что-то типа hard drive
seek  test  ;). Пример - в той же вынде выделите побольше иконок
на  рабочем  столе  и  нажмите  Enter  ;)  Поэтому  можно ввести
ограничение на одновременную работу не более 4*CPU скриптов враз.

DS>  > отдельно   от  других  подобных  ему.  И  тут  может  возникнуть
DS>  > нетривиальная  задача  развязки  обязательных  и  необязательных
DS>  > зависимостей.

DS> А в чём собственно её нетривиальность? Автор пакета должен суметь чётко
DS> сформулировать что необходимо его сервису для работы.

Нетривиальность вообще в создании такого дерева.

DS> Насчёт завязки на диск -- что это, например? Сервер БД на что больше
DS> завязан? IMHO сервер БД можно запускать как только смонтированы все
DS> разделы и подняты интерфейсы (если он не локальный).
то же самое можно сказать про большиснтво других сервисов.
Итак, fsck :), squid, smb
А в целом, да, ты прав, нужно какое-то другое деление.

DS> Для многопроцессорных систем польза от многопоточного запуска, IMHO,
DS> очевидна. 
Но не для hdd.

DS> Ещё можно вспонмить известный факт с многопроцессной компиляцией (make
DS> -jN), которая увеличивает скорость компиляции даже на однопроцессорных
DS> машинах.
Потому  что  тут  постоянно  запускаются  одни и те же программы
(gcc, make, ...), которые уже лежат в кэше.

DS>  > В  сам  S-скрипт (те, которые лежат в init.d) добавляем еще одно
DS>  > поле  типа  как это сделано для chkconfig. В этом поле указываем
DS>  > класс скрипта - дисковый или нет.

DS> Тоже вариант. Только вот с классом скрипта непонятно -- как их делить?
DS> Какой у Bind'а? А если он обслуживают тучу зон? А у иксов?
Думать надо...

DS>  > Можно  пойти  дальше  и  ввести  еще  одно  поле  в  S-скрипте -
DS>  > зависимость  от  уже  стартовавшего  сервиса.  Реализация именно
DS>  > такого  способа  задания  зависимостей  не  представляет  вообще
DS>  > никакого труда.

DS> Собственно этим и можно в результате сделать точно ту схему, о которой я
DS> писал выше. Только тогда придётся шерстить все скрипты.
 
И?

-- 
Best regards,
 ASA                            mailto:llb на udm.ru




Подробная информация о списке рассылки community