Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

3.6. Итоги 211

деления, скрывая детали, касающиеся связи с серверами, текущего местоположе-

ния серверов и репликации серверов. Кроме того, программное обеспечение

клиента способно частично скрыть возникающие сбои и процессы восстановле-

ния после сбоев.

Серверы часто сложнее клиентов, но тем не менее при их построении приме-

няется относительно немного архитектурных моделей. Так, например, серве-

ры могут быть итеративными или параллельными, реализовывать одну или не-

сколько служб, сохранять информацию о состоянии или не сохранять. Остальные

архитектурные особенности касаются адресации служб и механизмов прерыва-

ния серверов после прихода запроса на обслуживание и возможно в ходе его вы-

полнения.

Серверы объектов выделяются в особый класс. Коротко говоря, сервер объек-

тов

—

это процесс, содержащий размещенные в своем адресном пространстве объ-

екты и готовый принимать направленные к ним обращения. В отдельную катего-

рию серверы объектов выделяются во многом благодаря разнообразию способов

обращения к объектам. Так, например, сервер может запустить отдельный поток

выполнения для каждого запроса к объекту. С другой стороны, он может выде-

лять каждому объекту собственный поток выполнения или оставить единственный

поток выполнения для всех своих объектов. Посредством адаптера объектов в

различных серверах может быть реализована разная политика обращения к объ-

ектам. Коротко говоря, адаптер объектов

—

это компонент, реализующий только

одну политику обращения. На сервере может быть несколько адаптеров объектов.

Важной для распределенных систем темой является перенос кода с машины

на машину. Для того чтобы поддерживать перенос кода, имеются две веские при-

чины

—

повышенР1е производительности и мобильность. Если связь дорога, мы

можем иногда уменьшить взаимодействие, перенеся вычисления с сервера на

клиент и заставив клиент все что можно обрабатывать локально. Гибкость же

возрастает, когда клиент имеет возможность динамически загружать программ-

ное обеспечение, необходимое для работы с конкретным сервером. Загруженное

программное обеспечение может быть уже настроено на взаимодействие с этим

сервером, избавляя клиента от необходимости повторно устанавливать его до на-

чала работы.

Перенос кода приносит проблемы использования локальных ресурсов, свя-

занные с тем, что эти ресурсы также необходимо переносить на другие машины,

организовывать новые привязки кода к локальным ресурсам целевой машины

или задействовать глобальные ссылки. Другая проблема заключается в том, что

при переносе кода мы должны принимать во внимание гетерогенность системы.

Текущая практика показывает, что, возможно, лучшим средством справиться

гетерогенностью являются виртуальные машины, которые эффективно скры-

вают гетерогенность с помощью интерпретируемого кода.

И, наконец, программные агенты

—

специальный вртд процессов, работающих

как автономные модули, но способных кооперироваться с другими агентами.

точки зрения распределенных систем, отличие агентов от обычных приложе-

ний в том, что агенты взаимодействуют друг с другом посредством коммуника-

ционного протокола прикладного уровня, который называется языком взаи-

212 Глава 3. Процессы

модействия агентов (ACL). В ACL имеется четкое разделение между целью

сообщения и его содержимым. ACL определяет коммуникационный протокол верх-

него уровня: посылка сообщения обычно предполагает конкретную реакцию по-

лучателя на основании исключительно цели сообщения.

Вопросы и задания

в этом задании сравнивается чтение файлов с использованием однопоточно-

го и многопоточного файловых серверов. На то чтобы получить запрос, отве-

тить на него и совершить все прочие действия, у вас есть 15 мс. Считается,

что необходимые данные находятся в кэше основной памяти. Если потребу-

ются дисковые операции, как это происходит в трети случаев, нужно допол-

нительно 75 мс, в течение которых поток выполнения будет приостановлен.

Сколько запросов в секунду сможет выполнить однопоточный сервер?

мно-

гопоточный сервер?

Имеет ли смысл ограничивать число потоков выполнения серверного процесса?

В тексте мы описали многопоточный файловый сервер, показав, чем он луч-

ше однопоточного сервера и сервера на базе конечного автомата. Существуют

ли ситуации, в которых однопоточный сервер оказывается лучше? Приведите

пример.

Статически ассоциировать с облегченным процессом единственный поток

выполнения

—

это не самая лучшая идея. Почему?

Иметь в процессе только один облегченный процесс

—

также не лучшая идея.

Почему?

6. Опишите простую схему, в которой облегченных процессов столько же, сколь-

ко работающих потоков выполнения.

Заместители могут поддерживать прозрачность репликации, обращаясь к каж-

дой из реплик так, как описывалось в тексте. Может ли объект (на стороне

сервера) быть предметом реплицированного обращения?

8. Создание параллельных серверов путем порождения вложенных процессов име-

ет свои преимущества и недостатки по сравнению с многопоточными серве-

рами. Опишите их.

9. Набросайте архитектуру многопоточного сервера, поддерживающего посред-

ством сокетов несколько протоколов, и его интерфейса транспортного уровня

с базовой операционной системой.

10.

Как мы можем предотвратить игнорирование приложениями менеджера окон

и избежать полного беспорядка на экране?

И. Объясните, что такое адаптер объектов.

12.

Опишите некоторые особенности адаптера объектов, используемого для под-

держания сохранных объектов.

13.

Измените процедуру threacl_per_object в примере адаптера объектов (см. лис-

тинг 3.3) так, чтобы все объекты, контролируемые этим адаптером, обрабаты-

вались одним потоком выполнения.

3.6. Итоги 213

14.

Сервер, поддерживающий соединение TCP/IP с клиентом,

—

это сервер с фик-

сацией состояния или без фиксации состояния?

15.

Представьте себе web-сервер, поддерживающий таблицу, в которой IP-адреса

клиентов отображаются на наиболее часто посещаемые web-страницы. Когда

клиент соединяется с сервером, сервер находит клиента в своей таблице и,

если он обнаружен, возвращает записанную на него страницу. Это сервер с фик-

сацией состояния или без фиксации состояния?

16.

В какой степени обращение RMI, написанное на языке Java, зависит от пере-

носа кода?

17.

Сильная мобильность в UNIX-системах может обеспечиваться путем раз-

ветвления процесса с образованием дочернего процесса на удаленной маши-

не.

Опишите, как это работает.

18.

Из рис. 3.9 вытекает, что сильная мобильность не может сочетаться с вы-

полнением переносимого кода в процессе-получателе. Приведите обратный

пример.

19.

Рассмотрим процесс Р, который нуждается в доступе к файлу F, расположен-

ному на той же машине, на которой в настоящее время запущен процесс Р.

При переносе процесса Р на другую машину он по-прежнему требует доступа

к F. Если привязка файла к машине фиксирована, как можно реализовать

глобальную ссылку на F?

20.

Каждый агент в системе D'Agents реализуется в виде отдельного процесса.

Агенты могут связываться друг с другом, прежде всего, через совместно ис-

пользуемые файлы и путем обмена сообщениями. Файлы не могут выходить

за границы машин. В понятиях шаблона переноса, данных в разделе 3.4, какие

части состояния агента, представленные в табл. 3.3, относятся к сегменту ре-

сурсов?

21.

Сравните архитектуру D'Agents с архитектурой платформы агентов модели

FIPA.

22.

Куда в модели OSI поместить языки взаимодействия агентов (ACL)?

23.

Где в модели OSI размещались бы языки взаимодействия агентов (ACL),

будь они реализованы поверх системы обработки электронной почты, такой

как в D'Agents? Каковы были бы преимущества такого подхода?

24.

Почему часто необходимо указывать онтологию сообщения ACL?

Глава 4

И|\/1енование

4.1.

Именованные сущности

4.2.

Размещение мобильных сущностей

4.3.

Удаление

сущностей,

на которые нет ссылок

4.4. Итоги

Имена играют важную роль во всех компьютерных системах. Они необходимы

для совместного использования ресурсов, определения уникальных сущностей,

ссылок на местоположения и

т.

д.

Важная особенность именования состоит в том,

что имя может быть разрешено, предоставляя доступ к сущности, на которую оно

указывает. Разрешение имени, таким образом, представляет собой процесс досту-

па к именованной сущности. Для разрешения имен необходимо реализовать сис-

тему именования. Разница между именованием в распределенных и нераспреде-

ленных системах состоит в способе реализации систем именования.

В распределенных системах реализация системы именования часто сама по

себе распределена по нескольким машинам. Способ этого распределения играет

ключевую роль для эффективности и масштабируемости системы именования.

В этой главе мы сосредоточимся на трех различных, но одинаково важных спо-

собах использования имен в распределенных системах.

Во-первых, до обсуждения некоторых общих вопросов, связанных с именова-

нием, мы поближе рассмотрим организацию и реализацию «человеческих» имен.

Типичные примеры подобных имен включают в себя имена файловой системы

и World Wide Web. Построение глобальной масштабируемой системы именова-

ния имеет прямое отношение к этим типам имен.

Во-вторых, имена используются для локализации мобильных сущностей. Как

оказывается, системы именования на основе «человеческих» имен не особенно

подходят для поддержки большого количества мобильных сущностей, которые

вдобавок могут быть разбросаны по большой сети. Необходима альтернативная

организация, подобная той, что используется в мобильной телефонии, в которой

имена (идентификаторы) не зависят от местоположения.

Наша третья и последняя тема будет касаться организации имен. В частно-

сти,

имена, на которые больше не ссылается ни один объект и которые невоз-

4.1.

Именованные сущности 215

можно более локализовать, чтобы получить к ним доступ, должны автоматически

удаляться. Этот процесс также известен как уборка мусора, корни его следует

искать в языках программирования. Однако при переходе к крупным распреде-

ленным системам автоматическая уборка объектов, на которые нет ссылок, ста-

новится особенно важной.

4.1.

Именованные сущности

в этом разделе мы сначала сосредоточимся на различных типах имен и том, как

они организуются в пространства имен. Далее обсудим важный вопрос о том, как

разрешить имя, то есть каким образом получить доступ к сущности, на которую

оно указывает. Также мы коснемся различных аспектов, связанных с распределе-

нием по нескольким машинам больших пространств имен и их реализацией. В ка-

честве примеров больших служб именования мы рассмотрим систему доменных

имен Ир1тернета и стандарт OSI Х.500.

4.1.1.

Имена, идентификаторы и адреса

Имя в распределенной системе представляет собой строку битов, или символов,

используемую для ссылки на сущность. Сущностью в распределенной системе

является практически все. Типичными примерами являются ресурсы, включая

хосты, принтеры, диски, файлы. Другие хорошо известные примеры сущностей,

часто получающие имена,

—

это процессы, пользователи, почтовые ящики, группы

новостей, web-страницы, графические окна, сообщения, сетевые соединения и

т.

д.

С сущностями можно работать. Например, ресурс вроде принтера предостав-

ляет интерфейс, поддерживающий операции печати документа, запроса состоя-

ния печати и т. п. Кроме того, сущность, такая как сетевое соединение, может со-

вершать операции по передаче и приему данных, установки параметров качества

обслуживания, запроса состояния и т. д.

Чтобы работать с сущностью, необходимо иметь к ней доступ, для которого

мы используем точку

доступа {access

point). Точка доступа

—

это еще один спе-

циаттьный вид сущности в распределенных системах. Имя точки доступа называ-

ется

адресом

{address).

Адрес точки доступа сущности часто называют просто ад-

ресом сущности.

Сущность может иметь более чем одну точку доступа. Для сравнения, теле-

фон может считаться точкой доступа к человеку, если телефонный номер рас-

сматривать как адрес. Однако в наши дни множество людей имеет несколько те-

лефо1П1ых номеров, каждый из которых соответствует одной из точек доступа,

в которой этих людей можно застать. В распределенных системах типичным

примером точки доступа является хост, на котором запущен некий сервер. Его

адрес формируется сочетанием, например, IP-адреса и номера порта (то есть ад-

ресом сервера транспортного уровня).

Точка доступа сущности может с течением времени изменяться. Так, напри-

мер,

если мобильный компьютер перенести в другое место, ему, скорее всего,

216 Глава 4. Именование

будет присвоен не тот IP-адрес, который был у него раньше. Точно так же если

человек переезжает в другой город или другую страну, ему обычно приходится

менять телефон. Аналогично, смена работы или Интернет-провайдера влечет за

собой изменение адреса электронной почты.

Адрес

—

это специальный тип имени, указывающий на точку доступа к сущ-

ности. Поскольку точка доступа тесно связана с сущностью, кажется удобным

использовать адрес в качестве постоянного имени соответствующей сущности.

Однако делать это можно не всегда.

В трактовке адресов в качестве имен особого типа имеется множество досто-

инств. Так, например, нет ничего необыкновенного в регулярных реорганизаци-

ях распределенных систем, в результате которых какой-либо сервер, например

тот, который обрабатывает запросы FTP, оказывается на другом хосте. Та маши-

на, на которой этот сервер работал раньше, может быть перенацелена на совер-

шенно другую задачу, например резервное копирование локальных файловых

систем. Другими словами, сущность может с легкостью поменять точку доступа,

а точка доступа может быть перенацелена на другую сущность.

Если для ссылки на сущность использовать адрес, то после изменения точки

входа или назначения ее другой сущности мы получим неверную ссылку. Для

примера представьте себе, что FTP-служба организации известна только по ад-

ресу хоста, на котором запущен РТР-сервер. Как только сервер будет переведен

на другой хост, РТР-служба окажется абсолютно недоступной до тех пор, пока

новый адрес не станет известен всем пользователям этой службы. В этом случае

было бы значительно лучше сделать так, чтобы РТР-служба имела собственное

имя, никак не связанное с адресом соответствующего РТР-сервера.

Точно так же если сущность имеет более одной точки входа, непонятно, ка-

кой адрес использовать для ссылки. Например, как мы говорили в главе 1, мно-

жество организаций разносят свои web-службы по нескольким серверам. Если

мы будем использовать адреса этих серверов для ссылок на web-службы, неясно,

какой из адресов лучше выбрать. Значительно лучше использовать для web-

службы одно имя, не связанное с адресами web-серверов.

Эти прршеры иллюстрируют тот факт, что имя сущности, не связанное с ее

адресами, часто значительно проще и удобнее. Такие имена мы называем локаль-

но

независимыми {local

independent).

Кроме адресов существуют и другие типы имен, требующие особого рассмот-

рения, например имена, используемые для однозначной идентификации сущно-

сти.

Правильный идентификатор {true

identifier)

—

это имя со следующими свой-

ствами

[491]:

4 идентификатор ссылается не более чем на одну сущность;

> на каждую сущность ссылается не более одного идентификатора;

4 идентртфикатор всегда ссылается на одну и ту же сущность (то есть не мо-

жет быть использован повторно).

Использование идентификаторов значительно упрощает создание однознач-

ных ссылок на сущность. Для примера рассмотрим два процесса, каждый из ко-

торых ссылается на некие сущности посредством идентификаторов. Для того

4.1.

Именованные сущности 217

чтобы понять, что оба процесса ссылаются на одну и ту же сущность, достаточно

сравнить на эквивалентность два идентификатора. При использовании обычных

(не «идентификаторных») имен такого теста мало. Так, в качестве уникальной

ссылки на конкретного человека указывать только его имя и фамилию, напри-

мер «Джон Смит», явно недостаточно.

Точно так же если один и тот же адрес может быть присвоен другой сущ-

ности, мы не можем задействовать его в качестве идентификатора. Обсудим

использование телефонных номеров, которые относительно постоянны в том

смысле, что номер обычно относится к одному и тому же человеку или организа-

ции. Однако задействовать телефонный номер в качестве идентификатора нель-

зя,

потому что он с течением времени может поменяться. Соответственно, новая

булочная Боба может получить старый телефонный номер склада аппаратуры

Алисы. В этом случае лучше использовать правильный идентификатор Алисы,

не

ее телефонный номер.

Адреса и идентификаторы

—

два очень важных типа имен, каждый из которых

предназначен для своих целей. Во многих компьютерных системах адреса и иден-

тификаторы хранятся только в форме, удобной для использования машиной, то

есть в форме строк битов. Так, адреса Ethernet

—

это, по сути, случайные 48-бит-

ные строки. Адреса памяти обычно представлены 32- или 64-битными строками.

Еще один важный тип имен

—

имена,

приспособленные

для восприятия чело-

веком

(human-friendly names), или просто удобные для восприятия. В противо-

положность адресам и идентификаторам удобное для восприятия имя обычно

представляется в виде строки символов. Эти имена принимают множество раз-

личных форм. Например, файлы в UNIX-системах имеют имена, состоящие из

строк, длина которых может доходить до 255 символов и определяется только

желанием пользователя. Аналогично, имена DNS представляются относительно

простой строкой, символы в которой не зависят от регистра.

Пространства имен

Имена в распределенных системах организуются в некоторую сущность, которая

носит название

пространства имен

(пате

space).

Пространство имен может быть

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

Листовой

узел (leaf

node),

или лист, представлен именованной сущностью и не имеет исходящих

из

него ребер. Листовой узел обычно содержит информацию о представляемой

сущности

—

например, ее адрес,

—

к которой имеют доступ клиенты. С другой

стороны, мы можем сохранить в листовом узле состояние этой сущности

—

как

случае файловой системы, когда листовой узел содержит файл, который он

представляет. Позже мы еще вернемся к вопросу о содержимом узлов.

В противоположность листовому узлу, направляющий узел (directory node)

имеет несколько исходящих из него ребер, каждое их которых именовано, как

показано на рис.

4.1.

Каждый узел в графе именования рассматривается как еще

одна сущность распределенной системы и, следовательно, имеет отдельный иден-

тификатор. Направляющий узел хранит таблицу, в которой все исходящие ребра

представлены в виде пар (метка ребра, идентификатор узла). Эта таблица назы-

вается

направляющей

таблицей

(directory

table).

218

Глава 4. Именование

Данные, хранящиеся

в узле п1

home

п2:

пЗ:

п4:

"eike"

"max"

"steen"

keys

n5)"/keys"

7home/steen/keys"

keys

Листовой узел Q ^^^^^ j \ ^ribox

f) f) "/home/steen/mbox"

Рис.

4.1.

Обобщенный граф именования с одним корневым узлом

Граф именования, показанный на рисунке, имеет один узел, а именно

пО,

у ко-

торого имеются только исходящие ребра. Входящих ребер у него нет. Такой узел

называется

корневым

узлом

{root node)y

или

корнем,

графа именования. Несмотря

на то что граф именования может иметь несколько корневых узлов, для просто-

ты многие системы именования имеют лишь один корень. Любой путь в графе

именования должен быть представлен последовательностью меток, соответствую-

щих ребрам графа, например:

N:<label-1

, label-2, ..., Iabel-n>

Здесь

соответствует первому из узлов пути. Эта последовательность назы-

вается

именем

пути {path пате). Если первый узел пути

—

корень графа имено-

вания, это имя называется

абсолютгсым именем

пути

{absolute

path name). В про-

тивном случае оно называется

относительным именем

пути

{relative

path name).

Важно понимать, что имена всегда организуются в пространство имен. Вслед-

ствие этого имя всегда определяется только относительно направляющего узла.

В этом смысле термин «абсолютное имя»

—

это, в некотором смысле, обман.

Точно так же и разница между глобальными и локальными именами порой мо-

жет ввести в заблуждение.

Глобальным именем {global

пате) называется имя, ко-

торое обозначает одну и ту же сущность, вне зависимости от того, где в системе

оно используется. Другими словами, глобальное имя всегда соответствует одно-

му и тому же направляющему узлу. В противоположность ему, локальное имя

{local

пате)

—

это имя, интерпретация которого зависит от того, где это имя ис-

пользуется. Иначе говоря, локальное имя

—

это лишь относительное имя, и дол-

жен быть известен (подразумеваться) направляющий узел, к которому оно отно-

сится. Мы вернемся к этим вопросам, когда будем обсуждать разрешение имен.

Это описание графа именования похоже на реализацию многих файловых

систем. Однако вместо представления имени пути последовательностью имено-

ванных ребер, имена путей в файловых системах обычно представляются в виде

единой строки, в которой метки разделяются специальным разделяющим симво-

лом, например косой чертой (/). Этот символ также используется и для того,

чтобы показать, абсолютное это имя или нет. Например, вместо задания имени

пути в виде nOKhome, steen, mbox> (см. рис. 4.1) обычно используется его строко-

вое представление /home/steen/mbox. Отметим также, что если в один и тот же узел

4.1.

Именованные сущности 219

приходят несколько путей, этот узел может соответствовать различным именам

путей. Так, например, на узел п5 можно сослаться в виде /home/steen/keys или

просто в виде /keys. Строковое представление имени пути успешно применяется

к графу именования не только в файловых системах. В Plan 9 все ресурсы, как

то:

процессы, хосты, устройства ввода-вывода и сетевые интерфейсы, именуются

таким же образом, как файлы

[353].

Такой подход соответствует реализации

единого графа именования для всех ресурсов распределенной системы.

Существует множество различных способов организации пространства имен.

Как мы говорили, большая часть пространств имен имеют лишь один корневой

узел. Во многих случаях пространства имен имеют вдобавок жесткую иерархию,

то есть граф именования организован в виде дерева. Это означает, что каждый

узел, за исключением корневого, имеет лишь одно входящее в него ребро. Корне-

вой узел входящих ребер не имеет. Соответственно, каждый узел имеет лишь од-

но соответствующее ему абсолютное имя.

Граф именования, изображенный на рис. 4.1, является примером направлен-

ного ациклического графа {directed acyclic

graph).

При подобной организации узел

может иметь более одного входящего ребра, но граф не может иметь циклов. Су-

ществуют также пространства имен, не имеющие подобного ограничения.

Чтобы приблизить наши рассуждения к практике, рассмотрим способ именова-

ния файлов в стандартной файловой системе UNIX. В графе именования UNIX

направляющий узел соответствует файловому каталогу, а листовой узел

—

фай-

лу. Существует единственный корневой каталог, соответствующий в графе име-

нования корневому узлу. Реализация графа именования является составной ча-

стью файловой системы. Эта реализация состоит из непрерывного набора блоков

логического диска, обычно поделенных на загрузочный блок, суперблок, наборы

индексных узлов и блоки файловых данных [117, 319, 450]. Эта структура приве-

дена на рис. 4.2.

Суперблок

Загрузочный

блок

ч у

нд

ек(

'ЗЛ

:нь

Блоки файловых данных

Блок диска

Рис. 4.2. Обобщенная организация реализации файловой системы UNIX

на логическом диске в виде непрерывного набора дисковых блоков

Загрузочный блок

—

это специальный блок данных и инструкций, которые

автоматически загружаются в оперативную память при загрузке системы. Загрузоч-

ный блок используется при загрузке оперативной системы в основную память.

Суперблок содержит информацию обо всей файловой системе

—

это размер

незанятых дисковых блоков, неиспользованные индексные узлы и т. д. Индекс-

ные узлы нумеруются, начиная с нуля. Нуль зарезервирован для индексного уз-

ла, соответствующего корневому каталогу.

220 Глава 4. Именование

Каждый индексный узел содержит информацию о данных расположенного на

диске соответствующего файла. Кроме того, индексный узел содержит информа-

цию о своем владельце, времени создания и последней модификации, защите и

подобных же вещах. Соответственно, имея номер индексного узла, можно полу-

чить доступ к соответствующему файлу. Каждый из каталогов также реализован

в виде файла. Это относится и к корневому каталогу, который обеспечивает ото-

бражение между именами файлов и индексами индексных узлов. То есть индекс

индексного узла соответствует идентификатору узла в графе именования.

4.1.2.

Разрешение имен

Пространства имен предоставляют удобный способ сохранения и извлечения ин-

формации о сущностях по их именам. В общем виде, зная имя пути, можно из-

влечь всю информацию, которая хранится в узле, соответствующем этому имени.

Процесс поиска информации называется

разрешением

имени {пате

resolution).

Чтобы понять, как происходит разрешение имени, рассмотрим путь

N:<label-1,

label-2,

..., Iabel-n>. Разрешение этого имени начинается с узла

графа именова-

ния, при этом в направляющей таблице ищется имя label-1 и возвращается иденти-

фикатор узла, на который указывает это имя. Разрешение продолжается поис-

ком в направляющей таблице указанного узла имени 1аЬе1-2 и т. д. Предполагая,

что названный путь действительно существует, разрешение завершается при об-

наружении последнего узла, соответствующего имени label-n, возвращением со-

держимого этого узла.

При поиске имен возвращается идентификатор узла, с которого продолжает-

ся процесс разрешения. В частности, необходимо, получить доступ к направляю-

щей таблице найденного узла. Рассмотрим снова файловую систему UNIX. Как

уже говорилось, идентификатором узла является индекс (номер) индексного узла.

Доступ к направляющей таблице означает возможность сначала прочитать ин-

дексный узел, чтобы определить, где на диске находятся данные, а затем прочи-

тать блоки данных.

Механизм свертывания

Разрешение имен может происходить только в том случае, если мы знаем, откуда

и как начать. В нашем примере начальный узел задан, причем предполагается,

что мы знаем, как получить доступ к его направляющей таблице. Знание того, от-

куда и как начинать разрешение имен, называется

механизмом свертывания {closure

mechanism).

По существу, механизм свертывания относится к выбору начального

узла пространства имен, с которого должно начинаться разрешение имени

[367].

О функционировании механизмов свертывания иногда довольно трудно судить.

Это происходит из-за их частично неявной реализации и значительного отличия

друг от друга.

Так, например, разрешение имен в графе именования файловой системы UNIX

предполагает знание того факта, что индексный узел корневого каталога является

первым индексным узлом логического иска, на котором находится рассматри-

ваемая файловая система. Его истинное смещение в байтах вычисляется из зна-