вателю связей. Тем не менее, получение setuid-программами (к которым относится и программа mkdir) прав суперпользователя по отношению к удаленным файлам все еще остается общей проблемой, требующей своего решения. Возможно, что наи- лучшим решением этой проблемы было бы установление для файлов дополнительных характеристик, описывающих доступ к ним со стороны удаленных суперпользова- телей; к сожалению, это потребовало бы внесения изменений в структуру диско- вого индекса (в части добавления новых полей) и породило бы слишком большой беспорядок в существующих системах. 391 Если подпрограмма open завершается успешно, локальная библиотека остав- ляет об этом соответствующую отметку в доступной для пользователя структуре, содержащей адрес сетевого узла, идентификатор процесса-спутника, дескриптор файла и другую аналогичную информацию. Библиотечные подпрограммы read и write устанавливают, исходя из дескриптора, является ли файл удаленным, и в случае положительного ответа посылают спутнику сообщение. Процесс-клиент взаимодействует со своим спутником во всех случаях обращения к системным функциям, нуждающимся в услугах удаленной машины. Если процесс обращается к двум файлам, расположенным на одной и той же удаленной машине, он пользуется одним спутником, но если файлы расположены на разных машинах, используются уже два спутника: по одному на каждой машине. Два спутника используются и в том случае, когда к файлу на удаленной машине обращаются два процесса. Вызы- вая системную функцию через спутника, процесс формирует сообщение, включаю- щее в себя номер функции, имя пути поиска и другую необходимую информацию, аналогичную той, которая входит в структуру сообщения в системе с периферий- ными процессорами. Механизм выполнения операций над текущим каталогом более сложен. Когда процесс выбирает в качестве текущего удаленный каталог, библиотечная подп- рограмма посылает соответствующее сообщение спутнику, который изменяет теку- щий каталог, при этом подпрограмма запоминает, что каталог удаленный. Во всех случаях, когда имя пути поиска начинается с символа, отличного от нак- лонной черты (/), подпрограмма посылает это имя на удаленную машину, где процесс-спутник прокладывает маршрут, начиная с текущего каталога. Если те- кущий каталог - локальный, подпрограмма просто передает имя пути поиска ядру локальной системы. Системная функция chroot в отношении удаленного каталога выполняется похоже, но при этом ее выполнение для ядра локальной системы проходит незамеченным; строго говоря, процесс может оставить эту операцию без внимания, поскольку только библиотека фиксирует ее выполнение. Когда процесс вызывает функцию fork, соответствующая библиотечная подп- рограмма посылает сообщения каждому спутнику. Процессы -спутники выполняют операцию ветвления и посылают идентификаторы своих потомков клиенту-родите- лю. Процесс-клиент запускает системную функцию fork, которая передает управ- ление порождаемому потомку; локальный потомок ведет диалог с удаленным по- томком-спутником, адреса которого сохранила библиотечная подпрограмма. Такая трактовка функции fork облегчает процессам-спутникам контроль над открытыми файлами и текущими каталогами. Когда процесс, работающий с удаленными файла- ми, завершается (вызывая функцию exit), подпрограмма посылает сообщения всем его удаленным спутникам, чтобы они по получении сообщения проделали то же самое. Отдельные моменты реализации системных функций exec и exit затрагива- ются в упражнениях. Преимущество связи типа Newcastle состоит в том, что обращение процесса к удаленным файлам становится "прозрачным" (незаметным для пользователя), при этом в ядро системы никаких изменений вносить не нужно. Однако, данной разработке присущ и ряд недостатков. Прежде всего, при ее реализации возмож- но снижение производительности системы. В связи с использованием расширенной Си-библиотеки размер используемой каждым процессом памяти увеличивается, да- же если процесс не обращается к удаленным файлам; библиотека дублирует функ- ции ядра и требует для себя больше места в памяти. Увеличение размера про- цессов приводит к удлинению продолжительности периода запуска и может выз- вать большую конкуренцию за ресурсы памяти, создавая условия для более час- той выгрузки и подкачки задач. Локальные запросы будут исполняться медленнее из-за увеличения продолжительности каждого обращения к ядру, замедление мо- жет грозить и обработке удаленных запросов, затраты по пересылке которых по сети увеличиваются. Дополнительная обработка удаленных запросов на пользова- тельском уровне увеличивает количество переключений контекста, операций по выгрузке и подкачке процессов. Наконец, для того, чтобы обращаться к удален- ным файлам, программы должны быть перекомпилированы с использованием новых библиотек; старые программы и поставленные объектные модули без этого рабо- тать с удаленными файлами не смогут. Все эти недостатки отсутствуют в систе- 392 ме, описываемой в следующем разделе. 13.3 "ПРОЗРАЧНЫЕ" РАСПРЕДЕЛЕННЫЕ ФАЙЛОВЫЕ СИСТЕМЫ Термин "прозрачное распределение" означает, что пользователи, работающие на одной машине, могут обращаться к файлам, находящимся на другой машине, не осознавая того, что тем самым они пересекают машинные границы, подобно тому, как на своей машине они при переходе от одной файловой системе к другой пе- ресекают точки монтирования. Имена, по которым процессы обращаются к файлам, находящимся на удаленных машинах, похожи на имена локальных файлов: отличи- тельные символы в них отсутствуют. В конфигурации, показанной на Рисунке 13.10, каталог "/usr/src", принадлежащий машине B, "вмонтирован" в каталог "/usr/src", принадлежащий машине A. Такая конфигурация представляется удоб- ной в том случае, если в разных системах предполагается использовать один и тот же исходный код системы, традиционно находящийся в каталоге "/usr/src". Пользователи, работающие на машине A, могут обращаться к файлам, расположен- ным на машине B, используя привычный синтаксис написания имен файлов (напри- мер: "/usr/src/cmd/login.c"), и ядро уже само решает вопрос, является файл удаленным или же локальным. Пользователи, работающие на машине B, имеют дос- туп к своим локальным файлам (не подозревая о том, что к этим же файлам мо- гут обращаться и пользователи машины A), но, в свою очередь, не имеют досту- па к файлам, находящимся на машине A. Конечно, возможны и другие варианты, в частности, такие, в которых все удаленные системы монтируются в корне ло- кальной системы, благодаря чему пользователи получают доступ ко всем файлам во всех системах. Машина A Машина B +-----------------------------+ +-----------------------------+ | / | | / | | | | | | | | +--------+--------+ | | +-----------+-----------+ | | | | | | | | | | | bin usr | | usr bin etc | | | | | | | | | +----+----+ +----+--+ | | +-------+ | | | | | | | | | | | |login mail bin src| +--->src bin | | | | | | | | | | +---+---+ | | | | +------+-----+ | | | | | | | | | | | | | troff vi | | | | lib cmd uts | | | | | | | | | | | | | +---+---+ | | | | | | | | | | | | | | login.c mail.c | +---------------------------|-+ | +-----------------------------+ +---+ Рисунок 13.10. Файловые системы после удаленного монтирования Наличие сходства между монтированием локальных файловых систем и откры- тием доступа к удаленным файловым системам послужило поводом для адаптации функции mount применительно к удаленным файловым системам. В данном случае ядро получает в свое распоряжение таблицу монтирования расширенного формата. Выполняя функцию mount, ядро организует сетевую связь с удаленной машиной и 393 сохраняет в таблице монтирования информацию, характеризующую данную связь. Интересная проблема связана с именами путей, включающих "..". Если про- цесс делает текущим каталог из удаленной файловой системы, последующее ис- пользование в имени символов ".." скорее вернет процесс в локальную файловую систему, чем позволит обращаться к файлам, расположенным выше текущего ката- лога. Возвращаясь вновь к Рисунку 13.10, отметим, что когда процесс, принад- лежащий машине A, выбрав предварительно в качестве текущего каталог "/usr/src/cmd", расположенный в удаленной файловой системе, исполнит команду cd ../../.. текущим каталогом станет корневой каталог, принадлежащий машине A, а не ма- шине B. Алгоритм namei, работающий в ядре удаленной системы, получив после- довательность символов "..", проверяет, является ли вызывающий процесс аген- том процесса-клиента, и в случае положительного ответа устанавливает, трак- тует ли клиент текущий рабочий каталог в качестве корня удаленной файловой системы. Связь с удаленной машиной принимает одну из двух форм: вызов удаленной процедуры или вызов удаленной системной функции. В первой форме каждая про- цедура ядра, имеющая дело с индексами, проверяет, указывает ли индекс на удаленный файл, и если это так, посылает на удаленную машину запрос на вы- полнение указанной операции. Данная схема естественным образом вписывается в абстрактную структуру поддержки файловых систем различных типов, описанную в заключительной части главы 5. Таким образом, обращение к удаленному файлу может инициировать пересылку по сети нескольких сообщений, количество кото- рых определяется количеством подразумеваемых операций над файлом, с соответ- ствующим увеличением времени ответа на запрос с учетом принятого в сети вре- мени ожидания. Каждый набор удаленных операций включает в себя, по крайней мере, действия по блокированию индекса, подсчету ссылок и т.п. В целях усо- вершенствования модели предлагались различные оптимизационные решения, свя- занные с объединением нескольких операций в один запрос (сообщение) и с бу- феризацией наиболее важных данных (см. [Sandberg 85]). Сервер Клиент (процесс/процессор) +--------------------+ +----------------------------------------+ | таблица | | таблица таблица таблица | | индексов +-------+ | | индексов файлов пользо- | | +-----+ |Спутник|-| | +-----+ +-----+ ватель- | | | | +-+-----+ |- | | | | | ских | | +-----+ | | - +-----+ +-----+ дескрип- +-------+| | | | | +------+- -+-+ | | торов +--+Процесс|| | +-----+ | | | | +-----+ | +-----+ файла | +-------+| | | | | | | | | | +-+- -++ +-----+ | | | +-----+ | | | | +-----+ +-----+| | | | | | | | | | | | | | | || +-----+ |дескриптор | | +-----+ | | | | +-----+ +-----++-+- -+-+файла | | | --+----+-----+ | | | | | | +-----+ | | +-----+ | | +-----+ +-----+ | | | | | | +-----+ | +--------------------+ +----------------------------------------+ Рисунок 13.11. Открытие удаленного файла Рассмотрим процесс, который открывает удаленный файл "/usr/src/cmd/login.c", где "src" - точка монтирования. Выполняя синтакси- ческий разбор имени файла (по схеме namei-iget), ядро обнаруживает, что файл удаленный, и посылает на машину, где он находится, запрос на получение заб- локированного индекса. Получив желаемый ответ, локальное ядро создает в па- 394 мяти копию индекса, корреспондирующую с удаленным файлом. Затем ядро произ- водит проверку наличия необходимых прав доступа к файлу (на чтение, напри- мер), послав на удаленную машину еще одно сообщение. Выполнение алгоритма open продолжается в полном соответствии с планом, приведенным в главе 5, с посылкой сообщений на удаленную машину по мере необходимости, до полного окончания алгоритма и освобождения индекса. Взаимосвязь между структурами данных ядра по завершении алгоритма open показана на Рисунке 13.11. Если клиент вызывает системную функцию read, ядро клиента блокирует ло- кальный индекс, посылает запрос на блокирование удаленного индекса, запрос на чтение данных, копирует данные в локальную память, посылает запрос на ос- вобождение удаленного индекса и освобождает локальный индекс. Такая схема соответствует семантике существующего однопроцессорного ядра, но частота ис- пользования сети (несколько обращений на каждую системную функцию) снижает производительность всей системы. Однако, чтобы уменьшить поток сообщений в сети, в один запрос можно объединять несколько операций. В примере с функци- ей read клиент может послать серверу один общий запрос на "чтение", а уж сервер при его выполнении сам принимает решение на захват и освобождение ин- декса. Сокращения сетевого трафика можно добиться и путем использования уда- ленных буферов (о чем мы уже говорили выше), но при этом нужно позаботиться о том, чтобы системные функции работы с файлами, использующие эти буферы, выполнялись надлежащим образом. При второй форме связи с удаленной машиной (вызов удаленной системной функции) локальное ядро обнаруживает, что системная функция имеет отношение к удаленному файлу, и посылает указанные в ее вызове параметры на удаленную систему, которая исполняет функцию и возвращает результаты клиенту. Машина клиента получает результаты выполнения функции и выходит из состояния вызо- ва. Большинство системных функций может быть выполнено с использованием только одного сетевого запроса с получением ответа через достаточно приемле- мое время, но в такую модель вписываются не все функции. Так, например, по получении некоторых сигналов ядро создает для процесса файл с именем "core" (глава 7). Создание этого файла не связано с конкретной системной функцией, а завершает выполнение нескольких операций, таких как создание файла, про- верка прав доступа и выполнение ряда операций записи. В случае с системной функцией open запрос на исполнение функции, посыла- емый на удаленную машину, включает в себя часть имени файла, оставшуюся пос- ле исключения компонент имени пути поиска, отличающих удаленный файл, а так- же различные флаги. В рассмотренном ранее примере с открытием файла "/usr/src/cmd/login.c" ядро посылает на удаленную машину имя "cmd/login.c". Сообщение также включает в себя опознавательные данные, такие как пользова- тельский и групповой коды идентификации, необходимые для проверки прав дос- тупа к файлам на удаленной машине. Если с удаленной машины поступает ответ, свидетельствующий об успешном выполнении функции open, локальное ядро выби- рает свободный индекс в памяти локальной машины и помечает его как индекс удаленного файла, сохраняет информацию об удаленной машине и удаленном ин- дексе и по заведенному порядку выделяет новую запись в таблице файлов. В сравнении с реальным индексом на удаленной машине индекс, принадлежащий ло- кальной машине, является формальным, не нарушающим конфигурацию модели, ко- торая в целом совпадает с конфигурацией, используемой при вызове удаленной процедуры (Рисунок 13.11). Если вызываемая процессом функция обращается к удаленному файлу по его дескриптору, локальное ядро узнает из индекса (ло- кального) о том, что файл удаленный, формулирует запрос, включающий в себя вызываемую функцию, и посылает его на удаленную машину. В запросе содержится указатель на удаленный индекс, по которому процесс-спутник сможет идентифи- цировать сам удаленный файл. Получив результат выполнения любой системной функции, ядро может для его обработки прибегнуть к услугам специальной программы (по завершении которой ядро закончит работу с функцией), ибо не всегда локальная обработка резуль- татов, применяемая в однопроцессорной системе, подходит для системы с нес- колькими процессорами. Вследствие этого возможны изменения в семантике сис- 395 темных алгоритмов, направленные на обеспечение поддержки выполнения удален- ных системных функций. Однако, при этом в сети циркулирует минимальный поток сообщений, обеспечивающий минимальное время реакции системы на поступающие запросы. 13.4 РАСПРЕДЕЛЕННАЯ МОДЕЛЬ БЕЗ ПЕРЕДАТОЧНЫХ ПРОЦЕССОВ Использование передаточных процессов (процессов-спутников) в "прозрач- ной" распределенной системе облегчает слежение за удаленными файлами, однако при этом таблица процессов удаленной системы перегружается процессами-спут- никами, бездействующими большую часть времени. В других схемах для обработки удаленных запросов используются специальные процессы-серверы (см. [Sandberg 85] и [Cole 85]). Удаленная система располагает набором (пулом) процес- сов-серверов, время от времени назначаемых ею для обработки поступающих уда- ленных запросов. После обработки запроса процесс-сервер возвращается в пул и переходит в состояние готовности к выполнению обработки других запросов. Сервер не сохраняет пользовательский контекст между двумя обращениями, ибо он может обрабатывать запросы сразу нескольких процессов. Следовательно, каждое поступающее от процесса-клиента сообщение должно включать в себя ин- формацию о среде его выполнения, а именно: коды идентификации пользователя, текущий каталог, сигналы и т.д. Процессы-спутники получают эти данные в мо- мент своего появления или во время выполнения системной функции. Когда процесс открывает удаленный файл, ядро удаленной системы назначает индекс для последующих ссылок на файл. Локальная машина располагает таблицей пользовательских дескрипторов файла, таблицей файлов и таблицей индексов с обычным набором записей, причем запись в таблице индексов идентифицирует удаленную машину и удаленный индекс. В тех случаях, когда системная функция (например, read) использует дескриптор файла, ядро посылает сообщение, ука- зывающее на ранее назначенный удаленный индекс, и передает связанную с про- цессом информацию: код идентификации пользователя, максимально-допустимый размер файла и т.п. Если удаленная машина имеет в своем распоряжении про- цесс-сервер, взаимодействие с клиентом принимает вид, описанный ранее, одна- ко связь между клиентом и сервером устанавливается только на время выполне- ния системной функции. Если вместо процессов-спутников воспользоваться услугами серверов, уп- равление потоком данных, сигналами и удаленными устройствами может услож- ниться. Поступающие в большом количестве запросы к удаленной машине при от- сутствии достаточного числа серверов должны выстраиваться в очередь. Для этого нужен протокол более высокого уровня, чем тот, который используется в основной сети. В модели, использующей спутник, с другой стороны, перенасы- щенность запросами исключается, ибо все запросы клиента обрабатываются синх- ронно. Клиент может иметь не более одного запроса, ожидающего обработки. Обработка сигналов, прерывающих выполнение системной функции, при ис- пользовании серверов также усложняется, поскольку удаленной машине приходит- ся при этом искать соответствующий сервер, обслуживающий выполнение функции. Не исключается даже и такая возможность, что в связи с занятостью всех сер- веров запрос на выполнение системной функции находится в состоянии ожидания обработки. Условия для возникновения конкуренции складываются и тогда, когда сервер возвращает результат выполнения системной функции вызывающему процес- су и ответ сервера заключает в себе посылку через сеть соответствующего сиг- нального сообщения. Каждое сообщение должно быть помечено таким образом, чтобы удаленная система могла распознать его и в случае необходимости прер- вать работу процессов-серверов. При использовании спутников тот процесс, ко- торый обслуживает выполнение запроса клиента, идентифицируется автоматичес- ки, и в случае поступления сигнала проверка того, закончена ли обработка запроса или нет, не составляет особого труда. Наконец, если вызываемая клиентом системная функция заставляет сервер приостановиться на неопределенное время (например, при чтении данных с уда- 396 ленного терминала), сервер не может вести обработку других запросов, чтобы освободить тем самым серверный пул. Если к удаленным устройствам обращаются сразу несколько процессов и если при этом количество серверов ограничено сверху, имеет место вполне ощутимое узкое место. При использовании спутников этого не происходит, поскольку спутник выделяется каждому процессу-клиенту. Еще одна проблема, связанная с использованием серверов для удаленных устрой- ств, будет рассмотрена в упражнении 13.14. Несмотря на преимущества, которые предоставляет использование процес- сов-спутников, потребность в свободных записях таблицы процессов на практике становится настолько острой, что в большинстве случаев для обработки удален- ных запросов все-таки прибегают к услугам процессов-серверов. Пользователь +------------------------------+ | | Библиотека системных функций | | +------------------------------+ | | Уровень связи типа Newcastle | v +------------------------------+ ^ +------------------------------+ | | Подпрограмма обработки обра- | | | щения к системной функции | | +------------------------------+ + Периферийная | | Подпрограмма взаимодействия с<----+ система, | | удаленной файловой системой | | вызов удален- | +------------------------------+ + ной системы | | Подсистема управления файлами<------Вызов удален- Ядро +------------------------------+ ной процедуры Рисунок 13.12. Концептуальная схема взаимодействия с удален- ными файлами на уровне ядра 13.5 ВЫВОДЫ В данной главе нами были рассмотрены три схемы работы с расположенными на удаленных машинах файлами, трактующие удаленные файловые системы как рас- ширение локальной. Архитектурные различия между этими схемами показаны на Рисунке 13.12. Все они в свою очередь отличаются от многопроцессорных сис- тем, описанных в предыдущей главе, тем, что здесь процессоры не используют физическую память совместно. Система с периферийными процессорами состоит из сильносвязанного набора процессоров, совместно использующих файловые ресурсы центрального процессора. Связь типа Newcastle обеспечивает скрытый ("проз- рачный") доступ к удаленным файлам, но не средствами ядра операционной сис- темы, а благодаря использованию специальной Си-библиотеки. По этой причине все программы, предполагающие использовать связь данного типа, должны быть перекомпилированы, что в общем-то является серьезным недостатком этой схемы. Удаленность файла обозначается с помощью специальной последовательности сим- волов, описывающих машину, на которой расположен файл, и это является еще одним фактором, ограничивающим мобильность программ. В "прозрачных" распределенных системах для доступа к удаленным файлам используется модификация системной функции mount. Индексы в локальной систе- ме содержат отметку о том, что они относятся к удаленным файлам, и локальное ядро посылает на удаленную систему сообщение, описывающее запрашиваемую сис- темную функцию, ее параметры и удаленный индекс. Связь в "прозрачной" расп- ределенной системе поддерживается в двух формах: в форме вызова удаленной процедуры (на удаленную машину посылается сообщение, содержащее перечень операций, связанных с индексом) и в форме вызова удаленной системной функции (сообщение описывает запрашиваемую функцию). В заключительной части главы 397 рассмотрены вопросы, имеющие отношение к обработке дистанционных запросов с помощью процессов-спутников и серверов. 13.6 УПРАЖНЕНИЯ *1. Опишите реализацию системной функции exit в системе с периферийными процессорами. В чем разница между этим случаем и тем, когда процесс за- вершает свою работу по получении неперехваченного сигнала ? Каким обра- зом ядру следует сохранить дамп содержимого памяти ? 2. Процессы не могут игнорировать сигналы типа SIGKILL; объясните, что происходит в периферийной системе, когда процесс получает такой сигнал. *3. Опишите реализацию системной функции exec в системе с периферийными процессорами. *4. Каким образом центральному процессору следует производить распределение процессов между периферийными процессорами с тем, чтобы сбалансировать общую нагрузку ? *5. Что произойдет в том случае, если у периферийного процессора не окажет- ся достаточно памяти для размещения всех выгруженных на него процессов? Каким образом должны производиться выгрузка и подкачка процессов в сети? 6. Рассмотрим систему, в которой запросы к удаленному файловому серверу посылаются в случае обнаружения в имени файла специального префикса. Пусть процесс вызывает функцию execl("/../sftig/bin/sh","sh",0); Исполняемый модуль находится на удаленной машине, но должен выполняться в локальной системе. Объясните, каким образом удаленный модуль перено- сится в локальную систему. 7. Если администратору нужно добавить в существующую систему со связью ти- па Newcastle новые машины, то как об этом лучше всего проинформировать модули Си-библиотеки ? *8. Во время выполнения функции exec ядро затирает адресное пространство процесса, включая и библиотечные таблицы, используемые связью типа Newcastle для слежения за ссылками на удаленные файлы. После выполнения функции процесс должен сохранить возможность обращения к этим файлам по их старым дескрипторам. Опишите реализацию этого момента. *9. Как показано в разделе 13.2, вызов системной функции exit в системах со связью типа Newcastle приводит к посылке сообщения процессу-спутнику, заставляющего последний завершить свою работу. Это делается на уровне библиотечных подпрограмм. Что происходит, когда локальный процесс полу- чает сигнал, побуждающий его завершить свою работу в режиме ядра ? *10. Каким образом в системе со связью типа Newcastle, где удаленные файлы идентифицируются добавлением к имени специального префикса, пользова- тель может, указав в качестве компоненты имени файла ".." (родительский каталог), пересечь удаленную точку монтирования ? 11. Из главы 7 нам известно о том, что различные сигналы побуждают процесс сбрасывать дамп содержимого памяти в текущий каталог. Что должно прои- зойти в том случае, если текущим является каталог из удаленной файловой системы ? Какой ответ вы дадите в том случае, если в системе использу- ется связь типа Newcastle ? *12. Какие последствия для локальных процессов имело бы удаление из системы всех процессов-спутников или серверов ? *13. Подумайте над тем, как в "прозрачной" распределенной системе следует реализовать алгоритм link, параметрами которого могут быть два имени удаленных файлов, а также алгоритм exec, связанный с выполнением нес- кольких внутренних операций чтения. Рассмотрите две формы связи: вызов удаленной процедуры и вызов удаленной системной функции. *14. При обращении к устройству процесс-сервер может перейти в состояние приостанова, из которого он будет выведен драйвером устройства. Естест- венно, если число серверов ограничено, система не сможет больше удов- 398 летворять запросы локальной машины. Придумайте надежную схему, по кото- рой в ожидании завершения ввода-вывода, связанного с устройством, при- останавливались бы не все процессы-серверы. Системная функция не прек- ратит свое выполнение, пока все серверы будут заняты. +----------+ +----------+ +----------+ | Клиент A | | Клиент B | | Клиент C | +----------+ +----------+ +----------+ - - - - - - getty- - - - - - - процессы- - - - - - - - - - - - +-------------------------------------------+ терминаль- | - - - - - - | ный сервер +--+----+----------+----+-----------+----+--+ | | | | | | tty00 tty01 tty02 tty03 tty04 tty05 Рисунок 13.13. Конфигурация с терминальным сервером *15. Когда пользователь регистрируется в системе, дисциплина терминальной линии сохраняет информацию о том, что терминал является операторским, ведущим группу процессов. По этой причине, когда пользователь на клави- атуре терминала нажимает клавишу "break", сигнал прерывания получают все процессы группы. Рассмотрим конфигурацию системы, в которой все терминалы физически подключаются к одной машине, но регистрация пользо- вателей логически реализуется на других машинах (Рисунок 13.13). В каж- дом отдельном случае система создает для удаленного терминала getty-процесс. Если запросы к удаленной системе обрабатываются с по- мощью набора процессов-серверов, следует отметить, что при выполнении процедуры открытия сервер останавливается в ожидании подключения. Когда выполнение функции open завершается, сервер возвращается обратно в сер- верный пул, разрывая свою связь с терминалом. Каким образом осуществля- ется рассылка сигнала о прерывании, вызываемого нажатием клавиши "break", по адресам процессов, входящих в одну группу ? *16. Разделение памяти - это особенность, присущая локальным машинам. С ло- гической точки зрения, выделение общей области физической памяти (ло- кальной или удаленной) можно осуществить и для процессов, принадлежащих разным машинам. Опишите реализацию этого момента. *17. Рассмотренные в главе 9 алгоритмы выгрузки процессов и подкачки страниц по обращению предполагают использование локального устройства выгрузки. Какие изменения следует внести в эти алгоритмы для того, чтобы создать возможность поддержки удаленных устройств выгрузки ? *18. Предположим, что на удаленной машине (или в сети) случился фатальный сбой и локальный протокол сетевого уровня зафиксировал этот факт. Раз- работайте схему восстановления локальной системы, обращающейся к уда- ленному серверу с запросами. Кроме того, разработайте схему восстанов- ления серверной системы, утратившей связь с клиентами. *19. Когда процесс обращается к удаленному файлу, не исключена возможность того, что в поисках файла процесс обойдет несколько машин. В качестве примера возьмем имя "/usr/src/uts/3b2/os", где "/usr" - каталог, при- надлежащий машине A, "/usr/src" - точка монтирования корня машины B, "/usr/src/uts/3b2" - точка монтирования корня машины C. Проход через несколько машин к месту конечного назначения называется "мультискачком" (multihop). Однако, если между машинами A и C существует непосредствен- ная сетевая связь, пересылка данных через машину B была бы неэффектив- ной. Опишите особенности реализации "мультискачка" в системе со связью Newcastle и в "прозрачной" распределенной системе. 399