On Fri, May 09, 2003 at 11:39:59AM +0500, ASA wrote:

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

Это конфигурируемо должно быть. По-умолчанию 4*CPU -- оптимум.
 
 > DS>  > отдельно   от  других  подобных  ему.  И  тут  может  возникнуть
 > DS>  > нетривиальная  задача  развязки  обязательных  и  необязательных
 > DS>  > зависимостей.
 > DS> А в чём собственно её нетривиальность? Автор пакета должен суметь чётко
 > DS> сформулировать что необходимо его сервису для работы.
 > Нетривиальность вообще в создании такого дерева.

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

squid часть времени своего запуска почти не насилует хард. Кроме того кэш
сквида может случайно быть на другом харде. А smb при запуске вообще вроде
почти ничего не делает (разве что конфиги читает).

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

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

Это да. Но, IMHO, основные задержки при запуске системы сейчас это
DNS-запросы (и прочая сетевая активность) во время поднятия сервисов, и
таки загрузка процессора теми же скриптами.

 > DS>  > В  сам  S-скрипт (те, которые лежат в init.d) добавляем еще одно
 > DS>  > поле  типа  как это сделано для chkconfig. В этом поле указываем
 > DS>  > класс скрипта - дисковый или нет.
 > DS> Тоже вариант. Только вот с классом скрипта непонятно -- как их делить?
 > DS> Какой у Bind'а? А если он обслуживают тучу зон? А у иксов?
 > Думать надо...

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

Нужно чтобы всё работало даже для тех программ, которые об этой фиче не
знают. Если действительно сделать зависимостями по-умолчанию "все
предыдущие скрипты в списке", то действительно будет всё работать.
 
-- 
С уважением, Денис

http://freesource.info