Архитектура операционной системы UNIX - Морис Бах

Когда процесс вызывает функцию fork, соответствующая библиотечная подпрограмма посылает сообщения каждому спутнику. Процессы — спутники выполняют операцию ветвления и посылают идентификаторы своих потомков клиенту-родителю. Процесс-клиент запускает системную функцию fork, которая передает управление порождаемому потомку; локальный потомок ведет диалог с удаленным потомком-спутником, адреса которого сохранила библиотечная подпрограмма. Такая трактовка функции fork облегчает процессам-спутникам контроль над открытыми файлами и текущими каталогами. Когда процесс, работающий с удаленными файлами, завершается (вызывая функцию exit), подпрограмма посылает сообщения всем его удаленным спутникам, чтобы они по получении сообщения проделали то же самое. Отдельные моменты реализации системных функций exec и exit затрагиваются в упражнениях.

Преимущество связи типа Newcastle состоит в том, что обращение процесса к удаленным файлам становится "прозрачным" (незаметным для пользователя), при этом в ядро системы никаких изменений вносить не нужно. Однако, данной разработке присущ и ряд недостатков. Прежде всего, при ее реализации возможно снижение производительности системы. В связи с использованием расширенной Си-библиотеки размер используемой каждым процессом памяти увеличивается, даже если процесс не обращается к удаленным файлам; библиотека дублирует функции ядра и требует для себя больше места в памяти. Увеличение размера процессов приводит к удлинению продолжительности периода запуска и может вызвать большую конкуренцию за ресурсы памяти, создавая условия для более частой выгрузки и подкачки задач. Локальные запросы будут исполняться медленнее из-за увеличения продолжительности каждого обращения к ядру, замедление может грозить и обработке удаленных запросов, затраты по пересылке которых по сети увеличиваются. Дополнительная обработка удаленных запросов на пользовательском уровне увеличивает количество переключений контекста, операций по выгрузке и подкачке процессов. Наконец, для того, чтобы обращаться к удаленным файлам, программы должны быть перекомпилированы с использованием новых библиотек; старые программы и поставленные объектные модули без этого работать с удаленными файлами не смогут. Все эти недостатки отсутствуют в системе, описываемой в следующем разделе.

13.3 "ПРОЗРАЧНЫЕ" РАСПРЕДЕЛЕННЫЕ ФАЙЛОВЫЕ СИСТЕМЫ

Термин "прозрачное распределение" означает, что пользователи, работающие на одной машине, могут обращаться к файлам, находящимся на другой машине, не осознавая того, что тем самым они пересекают машинные границы, подобно тому, как на своей машине они при переходе от одной файловой системе к другой пересекают точки монтирования. Имена, по которым процессы обращаются к файлам, находящимся на удаленных машинах, похожи на имена локальных файлов: отличительные символы в них отсутствуют. В конфигурации, показанной на Рисунке 13.10, каталог "/usr/src", принадлежащий машине B, "вмонтирован" в каталог "/usr/src", принадлежащий машине A. Такая конфигурация представляется удобной в том случае, если в разных системах предполагается использовать один и тот же исходный код системы, традиционно находящийся в каталоге "/usr/src". Пользователи, работающие на машине A, могут обращаться к файлам, расположенным на машине B, используя привычный синтаксис написания имен файлов (например: "/usr/src/cmd/login.c"), и ядро уже само решает вопрос, является файл удаленным или же локальным. Пользователи, работающие на машине B, имеют доступ к своим локальным файлам (не подозревая о том, что к этим же файлам могут обращаться и пользователи машины A), но, в свою очередь, не имеют доступа к файлам, находящимся на машине A. Конечно, возможны и другие варианты, в частности, такие, в которых все удаленные системы монтируются в корне локальной системы, благодаря чему пользователи получают доступ ко всем файлам во всех системах.

Рисунок 13.10. Файловые системы после удаленного монтирования

Наличие сходства между монтированием локальных файловых систем и открытием доступа к удаленным файловым системам послужило поводом для адаптации функции mount применительно к удаленным файловым системам. В данном случае ядро получает в свое распоряжение таблицу монтирования расширенного формата. Выполняя функцию mount, ядро организует сетевую связь с удаленной машиной и сохраняет в таблице монтирования информацию, характеризующую данную связь.

Интересная проблема связана с именами путей, включающих "..". Если процесс делает текущим каталог из удаленной файловой системы, последующее использование в имени символов ".." скорее вернет процесс в локальную файловую систему, чем позволит обращаться к файлам, расположенным выше текущего каталога. Возвращаясь вновь к Рисунку 13.10, отметим, что когда процесс, принадлежащий машине A, выбрав предварительно в качестве текущего каталог "/usr/src/cmd", расположенный в удаленной файловой системе, исполнит команду

cd ../../..

текущим каталогом станет корневой каталог, принадлежащий машине A, а не машине B. Алгоритм namei, работающий в ядре удаленной системы, получив последовательность символов "..", проверяет, является ли вызывающий процесс агентом процесса-клиента, и в случае положительного ответа устанавливает, трактует ли клиент текущий рабочий каталог в качестве корня удаленной файловой системы.

Связь с удаленной машиной принимает одну из двух форм: вызов удаленной процедуры или вызов удаленной системной функции. В первой форме каждая процедура ядра, имеющая дело с индексами, проверяет, указывает ли индекс на удаленный файл, и если это так, посылает на удаленную машину запрос на выполнение указанной операции. Данная схема естественным образом вписывается в абстрактную структуру поддержки файловых систем различных типов, описанную в заключительной части главы 5. Таким образом, обращение к удаленному файлу может инициировать пересылку по сети нескольких сообщений, количество которых определяется количеством подразумеваемых операций над файлом, с соответствующим увеличением времени ответа на запрос с учетом принятого в сети времени ожидания. Каждый набор удаленных операций включает в себя, по крайней мере, действия по блокированию индекса, подсчету ссылок и т. п. В целях усовершенствования модели предлагались различные оптимизационные решения, связанные с объединением нескольких операций в один запрос (сообщение) и с буферизацией наиболее важных данных (см. [Sandberg 85]).

Рисунок 13.11. Открытие удаленного файла

Рассмотрим процесс, который открывает удаленный файл "/usr/src/cmd/login.c", где "src" — точка монтирования. Выполняя синтаксический разбор имени файла (по схеме namei-iget), ядро обнаруживает, что файл удаленный, и посылает на машину, где он находится, запрос на получение заблокированного индекса. Получив желаемый ответ, локальное ядро создает в памяти копию индекса, корреспондирующую с удаленным файлом. Затем ядро производит проверку наличия необходимых прав доступа к файлу (на чтение, например), послав на удаленную машину еще одно сообщение. Выполнение алгоритма open продолжается в полном соответствии с планом, приведенным в главе 5, с посылкой сообщений на удаленную машину по мере необходимости, до полного окончания алгоритма и освобождения индекса. Взаимосвязь между структурами данных ядра по завершении алгоритма open показана на Рисунке 13.11.

Если клиент вызывает системную функцию read, ядро клиента блокирует локальный индекс, посылает запрос на блокирование удаленного индекса, запрос на чтение данных, копирует данные в локальную память, посылает запрос на освобождение удаленного индекса и освобождает локальный индекс. Такая схема соответствует семантике существующего однопроцессорного ядра, но частота использования сети (несколько обращений на каждую системную функцию) снижает производительность всей системы. Однако, чтобы уменьшить поток сообщений в сети, в один запрос можно объединять несколько операций. В примере с функцией read клиент может послать серверу один общий запрос на "чтение", а уж сервер при его выполнении сам принимает решение на захват и освобождение индекса. Сокращения сетевого трафика можно добиться и путем использования удаленных буферов (о чем мы уже говорили выше), но при этом нужно позаботиться о том, чтобы системные функции работы с файлами, использующие эти буферы, выполнялись надлежащим образом.

При второй форме связи с удаленной машиной (вызов удаленной системной функции) локальное ядро обнаруживает, что системная функция имеет отношение к удаленному файлу, и посылает указанные в ее вызове параметры на удаленную систему, которая исполняет функцию и возвращает результаты клиенту. Машина клиента получает результаты выполнения функции и выходит из состояния вызова. Большинство системных функций может быть выполнено с использованием только одного сетевого запроса с получением ответа через достаточно приемлемое время, но в такую модель вписываются не все функции. Так, например, по получении некоторых сигналов ядро создает для процесса файл с именем "core" (глава 7). Создание этого файла не связано с конкретной системной функцией, а завершает выполнение нескольких операций, таких как создание файла, проверка прав доступа и выполнение ряда операций записи.