вателю
свЯзей.  ’ем  не  менее, получение 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