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

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

10.3.

Другие распределенные файловые системы 681

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

лизации

для

блоков данных,

их

которых состоят файлы.

наконец, клиент

{client)

xFS

—

это

процесс, который принимает запросы пользователей

на

вы-

полнение операций

файлами. Каждый клиент имеет возможность кэширова-

ния

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

Основная идея, положенная

основу xFS при проектировании этой системы,

состоит

том,

что

роли клиентов, менеджеров

серверов могут играть любые

машины.

полностью симметричной системе

на

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

все

три

процесса. Однако можно также использовать выделенные машины,

на

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

в то

время как

на

прочих

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

или

менеджеров.

По-

добный подход иллюстрирует рис. 10.29.

Клиент

Менеджер

Сервер

хранения

Клиент

Сервер

хранения

Сервер

хранения

Клиент

Менеджер

Рис. 10.29. Типичное распределение процессов xFS по нескольким машинам

Далее мы кратко рассмотрим общую структуру xFS. Детальное описание мож-

но найти

[15]. Опыт разработки xFS вместе

описанием технических деталей

изложены в

[488].

Что-то похожее на подход, принятый в xFS, то есть разнесение

единого хранилища на множество подключенных

сети дисков, описано

[166].

Авторы показали, каким образом можно использовать xFS-подобный способ рас-

пределения хранилищ

традиционных распределенных файловых системах,

та-

ких как NFS

AFS.

Связь

Изначально любое взаимодействие

xFS осуществлялись при помощи RPC. Од-

нако позже произошел отход

от

этой практики. Тому было несколько причин,

наиболее важной

из

которых следует считать потерю производительности. Дру-

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

основ-

ном

для

сквозной связи. Когда данные

управление полностью распределены

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

нескольких процессов. Серверы RPC требуют явного отслеживания ожидающих

обработки запросов

отождествления приходящих ответов

соответствующими

им запросами. Простое блокирование здесь

не

проходит.

По описанным причинам связь в xFS впоследствии была реализована посред-

ством активных

сообщений

{active

messages).

активных сообщениях [104,

478]

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

на

стороне

приемника

какие параметры

для

этого необходимы. Когда сообщение достав-

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

его

полную обработку.

682 Глава 10. Распределенные файловые системы

Пока работает обработчик, другие сообщения доставлены быть не могут. Основ-

ное достоинство такого подхода

—

его эффективность. Однако активные сообщения

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

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

ми,

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

полняющей обработчик машине.

Процессы

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

рили, все серверы хранения xFS вместе реализуют массив виртуальных дисков.

Точнее говоря, xFS реализует систему накопителей на основе разработанной

в Беркли [387] файловой системы со структурой лсурпала

{Log-Structured

File

System,

LFS).

В LFS различные операции записи, включая модификацию узлов индексов,

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

стно,

одной операцией. Все операции записи группируются в одном сегменте фик-

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

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

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

ная таблица

—

карта

индексов

(гтар), которая отображает ссылки таблицы ин-

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

появляется возможность найти и блоки файлов.

Для повышения производительности и доступности в xFS используется под-

ход, применявшийся в файловой системе

Zebra

[195],

в которой журнал, распре-

деленный по нескольким серверам, организован по аналогии с организацией

данных в RAID (рис. 10.30). Когда клиент добавляет к журналу очередной сег-

мент, он делит этот сегмент на несколько фрагментов одинакового размера, вы-

полняя так называемую нарезку

{striping).

Каждый из фрагментов сохраняется

на собственном сервере хранения. Клиент вычисляет также

фрагмент

паритета

{parity fragment), который хранится на дополнительном сервере. Если какой-ли-

бо из серверов перестанет работать, сегмент может быть восстановлен из фраг-

мента паритета и фрагментов, хранящихся на работоспособных серверах.

Серверы хранения в xFS организованы в группы нарезки

{stripe

groups).

При

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

резки. Этот способ отличается от принятого в Zebra, где части сегмента всегда

записываются на все серверы хранения. Использование для хранения групп на-

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

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

поддержке его частей) на всех серверах. Для того чтобы определить, какой сер-

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

лицируемая таблица.

Использование файловой системы со структурой журнала требует отслежи-

вания действительных мест хранения данных. Для этой цели каждый файл в xFS

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

дексов

—

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

10.3.

Другие распределенные файловые системы 683

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

изменения, индексный узел файла также может быть изменен. Это изменение,

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

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

нения в карту индексов.

Сегмент журнала

Гжурнал (уже сохраненный)!

Фрагмент

— Клиент разбивает

сегмент и вычисляет

фрагмент паритета

Фрагмент паритета

Серверы хранения

DEUCUil

Отправка фрагментов на серверы хранения

Рис. 10.30. Принцип нарезки

xFS

В xFS нет единого менеджера файлов. Управление файлами распределено ме-

жду несколькими менеджерами. Другими словами, в системе может одновремен-

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

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

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

неджера по идентификатору файла используется отдельная глобальная репли-

цируемая таблица

—

карта

менеджеров {manager

тар). Идентификатор файла

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

Если не принимать во внимание кэширование на клиентах, клиенты в xFS ис-

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

и запись файлов. Базовый подход к чтению блока данных b из файла / иллюст-

рирует рис.

10.31.

Клиент начинает с поиска файла/в каталоге, и это приносит

ему идентификатор файла/zW (mar 1). Полученный идентификатор использует-

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

жеров (шаг 2).

После того как менеджер найден, ему передаются значения fid и й, а затем по

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

(шаг 3). После этого в журнале находится точное местоположение индексного

узла. Это местоположение состоит из идентификатора группы нарезки, иденти-

фикатора сегмента и смещения в этом сегменте.

Все,

что нам теперь необходимо,

—

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

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

в которую записан нужный файл (шаг 4). В результате этой операции мы полу-

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

684

Глава 10. Распределенные файловые системы

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

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

ру адрес узла на диске (шаг 5). После этого шаги 4 и 5 повторяются с целью чте-

ния блока Ь.

Файл,

смещение

Индексный узел

Каталог Карта Карта

менеджеров индексов

Карта

группы

нарезки

Диск

Блок

данных

Карта Диск

группы

нарезки

Рис. 10.31. Чтение блока данных в xFS

Именование

Именование в xFS не представляет собой ничего сверхъестественного, за исклю-

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

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

фикаторы и структуры данных, применяемые в xFS, собраны в табл. 10.13 [16].

Таблица 10.13. Основные структуры данных в xFS

Структура данных Описание

Карта менеджеров

Карта индексов

Индексный узел

Идентификатор файла

Каталог файлов

Адрес в журнале

Карта группы нарезки

Отображение идентификатора файла на менеджера

Отображение идентификатора файла на адрес индексного

узла в журнале

Отображение номера блока (то есть смещения) на адрес

блока в журнале

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

менеджеров

Отображение имени файла на идентификатор файла

Группа из идентификатора группы нарезки, идентификатора

сегмента и смещения сегмента

Отображение идентификатора группы нарезки на список

серверов хранения

Кэширование

Клиенты в xFS поддерживают локальное кэширование блоков. Схема поддержа-

ния непротиворечивости похожа на соответствующую схему Coda за исключе-

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

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

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

10.3.

Другие распределенные файловые системы 685

решения на запись. Менеджер, в свою очередь, первым делом объявляет непра-

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

чего

дает разрешение на запись. Менеджер отслеживает, где имеются кэширован-

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

называется также текуш;им владельцем.

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

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

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

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

мент блок, находящийся в кэше текущего пользователя, сохраняется с целью пе-

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

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

В системе xFS реализуется также

кооперативное

кэширование

{collaborative

caching).

Согласно этой схеме, когда клиент хочет получить доступ к блоку дан-

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

Однако вместо поиска запрашиваемого блока на сервере хранения менеджер

первую очередь проверяет, не кэширует ли этот блок один из запросивших его

клиентов. Если это так, то клиент получает копию из кэша другого клиента.

Отказоустойчивость

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

держивают избыточность информации, доступность в xFS по сравнению с тради-

ционными подходами повышена. Если на одном из серверов случается сбой, его

фрагмент может быть восстановлен при помощи фрагмента паритета, хранящего-

ся на одном из других серверов. Если будет утерян фрагмент паритета, его можно

легко вычислить из существующих фрагментов. Тем не менее при сбое на не-

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

ные меры, а они-то в системе и не реализованы.

Восстановление состояния менеджеров реализовано путем записи контроль-

ных точек с обрабатываемыми менеджером данными. Одна из наиболее сложных

проблем

—

восстановление карты индексов. Установка контрольных точек спо-

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

внесенные после записи последней контрольной точки. Для этого клиенты от-

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

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

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

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

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

Восстановление в xFS реализовано только частично. Большинство необходимых

механизмов в реализацию прототипа не включены. Детали можно найти в [15].

Защита

Система xFS обеспечивает лишь минимальную защиту. Кроме реализации обыч-

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

686 Глава 10. Распределенные файловые системы

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

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

вать доступ не облеченных доверием клиентов NFS к набору машин xFS с исполь-

зованием защищенных вызовов RFC, которые мы обсуждали в пункте 10.1.8. На

самом деле клиент NFS путем защищенного вызова RPC связывается с клиентом

xFS.

В этом случае клиент xFS играет для клиента NFS роль сервера NFS.

10.3.3.

SFS

—

масштабируемая защита

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

совершенно осо-

бым подходом к обеспечению защиты. В

защищенной

файловой

системе

{Secure

File

System,

SFS) основной особенностью является отделение средств управления

ключами от средств защиты файловой системы (см. [287]). Другими словами,

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

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

сит от доступа к файлам.

Обзор

Общая структура SFS представлена на рис. 10.32. Для того чтобы обеспечить со-

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

скольких компонентов NFS версии 3. На машине клиента помимо программы

пользователя размещаются три разных компонента системы. Клиент NFS исполь-

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

с клиентом SFS. Последний представляется клиенту NFS в качестве сервера NFS.

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

му ONC RPC по протоколу NFS.

Машина клиента

Программа

пользователя

Клиент

NFS

Пользовательский

агент

^ W

RPC

Клиент

SFS

Машина

сервера

Сервер

аутентификации

Клиент

SFS

;

^ W

RPC

J Клиент

1 NFS

Рис. 10.32, Структура SFS

Клиент SFS отвечает за организацию защищенного канала с сервером SFS.

Он отвечает также за связь с локальным

пользовательским агентом

(user agent)

10.3.

Другие распределенные файловые системы 687

SFS,

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

идентификацию пользователя. SFS не предписывает способ аутентификации поль-

зователей. В соответствии с принципами своего создания, SFS выделяет этот про-

цесс в отдельную задачу и использует разные агенты для разных протоколов

аутентификации пользователя.

Со стороны сервера также имеется три компонента. Из соображений перено-

симости по-прежнему используется сервер

NFS.

Этот сервер поддерживает связь

с сервером SFS, который для сервера NFS представляется клиентом NFS. Сервер

SFS создает процесс ядра SFS, который отвечает за обработку файловых запро-

сов клиентов SFS. Аналогично агенту SFS сервер SFS для аутентификации поль-

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

Связь

Клиент SFS и сервер SFS взаимодействуют по немного адаптированному вариан-

ту протокола NFS версии

Когда клиент открывает файл, он получает атрибуты

файла, которые также могут быть кэшированы. В SFS кэширование этих атрибу-

тов ограничено арендой. Когда срок аренды истекает, клиент SFS считает атрибу-

ты файла не соответствующими действительности. Кроме того, сервер SFS по-

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

соответствующими действительности. Фактически SFS выглядит как дополне-

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

в настоящее время реализованы в NFS версии 4.

Процессы

Как можно видеть на рис. 10.32, SFS представляет собой традиционную систему

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

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

стоположение. Другими словами, клиент SFS абсолютно независим от местопо-

ложения пользователя SFS. Подобный подход совпадает с идеей о том, что поль-

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

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

предоставляет право на доступ пользователям.

Именование

Уникальной по сравнению с другими распределенными файловыми системами

SFS делает организация пространства имен. SFS поддерживает глобальное про-

странство имен с корнем в каталоге под названием /sfs. Клиент SFS позволяет

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

ские ссылки.

Что более важно, SFS использует в качестве имен файлов самосертифици-

рующиеся имена путей {self-certifying

pathnames).

Эти имена, в сущности, несут

всю информацию, необходимую для аутентификации сервера SFS, на котором

находится файл, идентифицируемый таким именем. Самосертифицирующееся имя,

как видно на рис.

10.33,

состоит из трех частей.

688 Глава 10. Распределенные файловые системы

|/sfs|

LOC I HID I Имя пути |

/Sfs/sfs.vu.cs.nl:ag62hty4wior450hdh63u62i4f0kqere/home/steen/mbox

Рис. 10.33. Самосертифицирующееся имя в SFS

Первая часть имени (LOC) определяет местоположение, которое представля-

ет собой либо доменное имя DNS, идентифицирующее сервер SFS, либо соответ-

ствующий ему IP-адрес. SFS предполагает, что каждый сервер S имеет соответ-

ствующий открытый ключ

Ks>

Вторая часть самосертифицирующегося имени

(HID)

—

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

тографической хэш-функции я по месторасположению сервера и его открытому

ключу:

HID = Я (LOQ

К^зУ

HID представляет собой число из 32 цифр в системе счисления по основа-

нию 32. Третья часть образована локальным именем пути сервера SFS, на кото-

ром находится файл.

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

цировать этот сервер, просто запросив у него открытый ключ. Используя извест-

ную функцию хэширования Я, клиент может вычислить HID и сверить его со

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

уверен, что имеет дело с сервером, носящим искомое имя. После этого сервер

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

дит независимо от SFS. В [287] описана реализация, при которой клиент исполь-

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

и аутентификации на сервере.

Защита

Как отделить механизм управления ключами от механизмов защиты файловой

системы? Эту проблему решает SFS. Один из способов получения ключа серве-

ра

—

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

описано. Однако можно также хранить коллекцию ключей локально, например

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

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

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

стоположению.

Прозрачность именования, позволяющая упростить этот процесс, может быть

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

хочет получить доступ к файлу по имени:

/Sfs/sfs.vu.cs.nl:ag62hty4wior450hdh63u62i4f0kqere/home/steen/nnbox

Чтобы скрыть имя хоста, пользователь может создать символическую ссылку:

/sfs/vucs —> /Sfs/sfs.vu.cs.nl:ag62hty4wior450hdh63u62i4f0kqere

После этого достаточно использовать только имя /sfs/vucs/home/steen/mbox.

При разрешении это имя будет автоматически расширено до полного имени SFS,

10.4.

Сравнение распределенных файловых систем 689

а найденный локально открытый ключ позволит идентифицировать сервер SFS

sfs.vu.cs.nl.

Таким же образом SFS может поддерживаться сертифицирующими организа-

циями. Обычно подобная организация поддерживает ссылки на серверы SFS,

с которыми она работает. В качестве примера рассмотрим сертифицирующую

организацию (С4), которая запускает сервер SFS по имени:

/sfs/sfs.certsfs.com:kty83pad72qmbna9uefdppioq7053jux

Предположим, что у клиента уже установлена символическая ссылка:

/certsfs —-> /sfs/sfs.certsfs.com: kty83pad72qmbna9uefdppioq7053jux

Тогда сертифицирующая организация может использовать другую символи-

ческую ссылку:

/vucs —> /Sfs/sfs.vu.cs.nl:ag62hty4wior450hdh63u62i4f0kqere

Эта ссылка указывает на сервер SFS sfs.vu.cs.nl. Тогда клиент может просто

сослаться на /certsfs/vucs/home/steen/mbox, и это будет означать, что он запра-

шивает файловый сервер, открытый ключ которого сертифицирован организа-

цией СЛ.

Эти примеры по методам управления ключами взяты из

[287].

Детальное опи-

сание реализации и вопросов производительности SFS можно найти в

[286].

Там

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

для обеспечения защиты.

10.4. Сравнение распределенных

файловых систем

Мы обсудили пять разных файловых систем. Хотя эти системы имеют много об-

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

систем, обращая особое внимание на NFS и Coda.

10.4.1.

Философия

Цели разработки файловых систем часто весьма разнятся. NFS

—

это в основном

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

конкретного удаленного сервера.

этом смысле она похожа на системы объектов,

которые поддерживают только удаленные объекты. Разработчики NFS версии 4

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

нет задержки на передачу данных. Этого удалось добиться путем полного кэши-

рования файлов на клиенте и локального выполнения всех операций.

Основная цель разработки Coda состояла в обеспечении доступности даже

в случае разрывов в сети и работе в автономном режиме. Система Coda также со-

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

бируемость. Сочетание высокой доступности и масштабируемости вьщеляет Coda

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

690 Глава 10. Распределенные файловые системы

Система Plan 9 в первую очередь являет собой распределенную систему раз-

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

разно, а именно в форме доступа к файлам. Как мы показали, система Plan 9 мо-

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

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

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

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

целей xFS добивается в условиях отсутствия выделенных серверов, что, собст-

венно, и являлось основной целью разработчиков.

Система SFS предназначена для масштабирования системы защиты. Она вы-

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

системой и вопросов ее защиты. Любому пользователю позволяется запустить соб-

ственную службу SFS, не внося изменений в работу централизованных служб.

Важную роль в этом играет организация пространства имен

—

в имя файла вклю-

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

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

файлов, поддерживаемых каждой из систем. Так, например, NFS, Plan 9 и SFS

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

чает сервер, совершающий все операции с файлами. Можно считать, что Coda,

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

ки.

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

унаследовала от AFS. В XFS используется совершенно другой подход, в котором

реализация файловой системы имеет структуру журнала.

10.4.2.

Связь

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

шинстве распределенных файловых систем применяется та или иная форма вы-

зовов RPC. NFS, Coda и SFS прямо используют базовую систему RPC, которая

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

Можно сказать, что Plan 9 также использует RPC, но реальный протокол был

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

других протоколов.

Полезно отметить, что разработчики xFS тоже начали с организации взаимо-

действия при помощи вызовов RPC. Однако для повышения производительно-

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

вызовам RPC пришли активные сообщения.

10.4.3.

Процессы

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

ют в файловой системе. В структуре систем клиент-сервер, описанной в главе 1,

в NFS версии 3 клиентский процесс может, в сущности, быть «тонким». Другими

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

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