Способы распространения модификаций

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

Для решения этой проблемы необходимо, чтобы модификации данных, выпол­ненные над одной из копий, были своевременно распространены на все осталь­ные копии. Существует несколько вариантов распространения модификаций. От выбранного варианта в значительной степени зависит семантика разделения файлов.

Одним из путей решения проблемы согласования является использование алго­ритма сквозной записи. Когда кэшируемый элемент (файл или блок) модифици­руется, новое значение записывается в кэш и одновременно посылается на сер­вер для обновления главной копии файла. Теперь другой процесс, читающий этот файл, получает самую последнюю версию данных. Данный вариант распростра­нения модификаций обеспечивает семантику разделения файлов в стиле UNIX.

Один из недостатков алгоритма сквозной записи состоит в том, что он уменьша­ет интенсивность сетевого обмена только при чтении, при записи интенсивность сетевого обмена та же самая, что и без кэширования. Многие разработчики сис­тем находят это неприемлемым и предлагают следующий алгоритм отложенной записи: вместо того чтобы выполнять запись на сервер, клиент просто помечает, что файл изменен. Примерно каждые 30 секунд все изменения в файлах собира­ются вместе и отсылаются на сервер за один прием. Одна большая запись для се­тевого обмена обычно более эффективна, чем множество коротких.

Следующим шагом в этом направлении является принятие сеансовой семанти­ки, в соответствии с которой запись файла на сервер производится только после закрытия файла. Этот алгоритм называется «запись по закрытию» и приводит к тому, что если две копии одного файла кэшируются на разных машинах и по­следовательно записываются на сервер, то второй записывается поверх первого. Данная схема не может снизить сетевой трафик, если объем изменений за сеанс редактирования файла невелик.

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

Проверка достоверности кэша

Распространение модификаций решает только проблему согласования главной копии файла, хранящейся на сервере, с клиентскими копиями. В то же время этот прием не дает никакой информации о том, когда должны обновляться дан­ные, находящиеся в кэшах клиентов. Очевидно, что данные в кэше одного клиен­та становятся, недостоверными, когда данные, модифицированные другим кли­ентом, переносятся в главную копию файла. Следовательно, необходимо каким-то образом проверять, являются ли данные в кэше клиента достоверными. В про­тивном случае данные кэша должны быть повторно считаны с сервера. Сущест­вуют два подхода к решению этой проблемы — инициирование проверки клиен­том и инициирование проверки сервером.

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

· Перед каждым доступом к файлу. Этот способ дискредитирует саму идею кэ­ширования, так как каждое обращение к файлу вызывает обмен по сети с сер­вером. Но зато это обеспечивает семантику разделения файлов UNIX.

· Периодические проверки. Улучшают производительность, но делают семан­тику разделения неясной, зависящей от временных соотношений.

· Проверка при открытии файла. Этот способ подходит для сеансовой семанти­ки. Необходимо отметить, что сеансовая семантика требует одновременного применения модели доступа загрузки-выгрузки, метода распространения мо­дификаций «запись по закрытию» и проверки достоверности кэша при от­крытии файла.

Совершенно другой подход к проблеме проверки достоверности кэша реализуется при инициировании проверки сервером, который также можно назвать методом централизованного управления. Когда файл открывается, то клиент, выполняю­щий это действие, посылает соответствующее сообщение файловому серверу, в котором указывает режим открытия файла — чтение или запись. Файловый сер­вер сохраняет информацию о том, кто и какой файл открыл, а также о том, от­крыт файл для чтения, для записи или для того и другого. Если файл открыт для чтения, то нет никаких препятствий для разрешения другим процессам открыть его для чтения, но открытие его для записи должно быть запрещено. Аналогич­но, если некоторый процесс открыл файл для записи, то все другие виды досту­па должны быть запрещены. При закрытии файла также необходимо оповестить файловый сервер для того, чтобы он обновил свои таблицы, содержащие данные об открытых файлах. Модифицированный файл также может быть выгружен на сервер в такой момент.

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

· отвергнуть запрос;

· поместить запрос в очередь;

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

Подход, основанный на централизованном управлении, весьма эффективен, обеспечивает семантику разделения UNIX, но обладает следующими недостат­ками:

· Он отклоняется от традиционной модели взаимодействия клиента и сервера, при которой сервер только отвечает на запросы, инициированные клиентами. Это делает код сервера нестандартным и достаточно сложным.

· Сервер обязательно должен хранить информацию о состоянии сеансов кли­ентов, то есть иметь тип stateful.

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

Репликация

Сетевая файловая система может поддерживать репликацию (тиражирование) файлов в качестве одной из услуг, предоставляемых клиентам. Иногда реплика­цией занимается отдельная служба ОС. Репликация (replication) подразумевает существование нескольких копий одного и того же файла, каждая из которых хранится на отдельном файловом сервере, при этом обеспечивается автоматиче­ское согласование данных в копиях файла.

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

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

□ Распределение нагрузки между несколькими серверами. Клиенты могут об­ращаться к данным реплицированного файла на ближайший файловый сер­вер, хранящий копию этого файла. Ближайшим может считаться сервер, на­ходящийся в той же подсети, что и клиент, или же первый откликнувшийся, или же выбранный некоторым сетевым устройством, балансирующим нагруз­ки серверов, например коммутатором 4-го уровня.

Репликация похожа на кэширование файлов на стороне клиентов тем, что в сис­теме создается несколько копий одного файла. Однако существуют и принци­пиальные отличия репликации от кэширования, прежде всего в преследуемых целях. Если кэширование предназначено для обеспечения локального доступа к файлу одному клиенту и повышения за счет этого скорости работы этого клиен­та, то репликация нужна для повышения надежности хранения файлов и сниже­ния нагрузки на файловые серверы. Реплики файла доступны всем клиентам, так как хранятся на файловых серверах, а не на клиентских компьютерах, и о су­ществовании реплик известно всем компьютерам сети. Файловая система обес­печивает достоверность данных реплики и защиту ее данных.

Прозрачность репликации

Как обычно, ключевым вопросом, связанным с репликацией, является прозрач­ность. До какой степени пользователи должны быть в курсе того, что некоторые. файлы реплицируются? Должны они играть какую-либо роль в процессе репли­кации или репликация должна выполняться полностью автоматически? В одних системах^ пользователи полностью вовлечены в этот процесс, в других система все делает без их ведома. В последнем случае говорят, что система репликацион-но прозрачна.

Прозрачность репликации зависит от двух факторов: используемой схемы име­нования реплик и степени вовлеченности пользователя в управление реплика­цией.

Именование реплик. Прозрачность доступа к файлу, существующему в виде не­скольких реплик, может поддерживаться системой именования, которая отобра­жает имя файла на его сетевой идентификатор, однозначно определяющий место хранения файла. Если в сети используется централизованная справочная служ­ба, которая позволяет хранить отображения имен объектов на их сетевые иден­тификаторы (например, IP-адреса серверов), то для реплицированных файлов допустима прозрачная схема именования. В этом случае файлу присваивается имя, не содержащее старшей части, соответствующей имени компьютера. В спра­вочной службе этому имени соответствует несколько идентификаторов, указы­вающих на серверы, хранящие реплики файла. При обращении к такому файлу приложение использует имя, а справочная система возвращает ему один из идентификаторов, указывающий на сервер, хранящий реплику.

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

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

□ При явной репликации {explicit replication) пользователю (или прикладному программисту) предоставляется возможность управления процессом репли­кации. При создании файла сначала создается первая реплика с явным указа­нием сервера, на котором размещается файл, а затем создается несколько реплик, причем для каждой реплики сервер также указывается явно. Пользо­ватель при желании может впоследствии удалить одну или несколько реп­лик. Явная репликация не исключает автоматического режима поддержания согласованности реплик, которые создал и разместил на серверах пользова­тель.

□ При неявной репликации (implicit replication) выбор количества и места разме­щения реплик производится в автоматическом режиме, без участия пользова­теля. Приложение не должно указывать место размещения файла при запросе на его создание. Файловая система самостоятельно выбирает сервер, на кото­рый помещает первую реплику файла. Затем в фоновом режиме система со­здает несколько реплик этого файла, выбирая их количество и серверы для их размещения. Если надобность в некоторых репликах исчезает (это также определяется автоматически), то система их удаляет.

Согласование реплик

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

Чтение любой — запись во все (Read-Any — Write-All). При необходимости запи­си в файл все реплики файла блокируются, затем выполняется запись в каждую копию, после чего блокировка снимается и файл становится доступным для чте­ния. Чтение может выполняться из любой копии. Этот способ обеспечивает семантику разделения файлов в стиле UNIX. Недостатком является то, что за­пись не всегда можно осуществить, так как некоторые серверы, хранящие репли­ки файла, могут в момент записи быть неработоспособными.

Запись в доступные (Available-Copies). Этот метод снимает ограничение преды­дущего, так как запись выполняется только в те копии, серверы которых доступ­ны на момент записи. Чтение осуществляется из любой реплики файла, как и в предыдущем методе. Любой сервер, хранящий реплику файла, после перезагруз­ки должен соединиться с другим сервером и получить от него обновленную ко­пию файла и только потом начать обслуживать запросы на чтение из файла. Для обнаружения отказавших серверов в системе должен работать специальный про­цесс, постоянно опрашивающий состояние серверов. Недостатком метода явля­ется возможность появления несогласованных копий файла из-за коммуникаци­онных проблем в сети, когда невозможно выявить отказавший сервер.

Первичная реплика {Primary-Copy). В этом методе запись разрешается только в одну реплику файла, называемую первичной (primary). Все остальные реплики файла являются вторичными (secondary), и из них можно только читать данные. После модификации первичной реплики все серверы, хранящие вторичные реп­лики, должны связаться с сервером, поддерживающим первичную реплику, и по­лучить от него обновления. Этот процесс может инициироваться как первичным сервером, так и вторичными (периодически проверяющими состоянии первич­ной реплики). Это метод является одной из реализаций метода «чтение любой — запись во все», в которой процесс записи реализован иерархическим способом. Для аккумулирования нескольких модификаций и сокращения сетевого трафи­ка распространение модификаций может быть выполнено с запаздыванием, но в этом случае ухудшается согласованность копий. Недостатком метода является его низкая надежность — при отказе первичного сервера модификации файла невозможны (для решения этой проблемы необходимо повысить статус некото­рого вторичного сервера до первичного).

Кворум (Quorum). Этот метод обобщает подходы, реализованные в предыдущих методах. Пусть в сети существует п реплик некоторого файла. Алгоритм основан на том, что при модификации файла изменения записываются в w реплик, а при чтении файла клиент обязательно производит обращение к г репликам. Значе­ния w и г выбираются так, что w+r>n. При чтении клиент должен иметь возмож­ность сначала проверить версию каждой реплики, а затем выбрать старшую и читать данные уже из нее. Очевидно, что при модификации файла номер версии должен наращиваться, а если при записи в w реплик они имеют разные версии, то выбирается максимальное значение версии для наращивания и присваивания всем репликам.

При выполнении условия w+r > n среди любых выбранных произвольным обра­зом г реплик всегда найдется хотя бы одна из w реплик, в которую были записа­ны последние обновления. Так, если реплик восемь (п = 8), можно выбрать в ка­честве г значение 4, а в качестве w — значение 5 (рис. 10.7). Условие w+r>n при этом удовлетворяется.

Предположим, что запись последних изменений была выполнена в реплики с но­мерами 3,4,5, 6,8. Если при чтении выбраны реплики 1,2,3, 7, то реплика 3 ока­жется общей для операций записи и чтения, поэтому прочитаны будут коррект­ные данные. В другом примере, который тоже иллюстрирует рисунок, r выбрано равным 2, a w — 7. Результат также получен корректный.

У метода кворума имеются частные случаи. Так, если г = 1, a w = п, то получаем метод «чтение любой — запись во все».

Примеры сетевых файловых служб: FTP и NFS Протокол передачи файлов FTP

Сетевая файловая служба на основе протокола FTP {File Transfer Protocol) пред­ставляет собой одну из наиболее ранних служб, используемых для доступа к удаленным файлам. До появления службы WWW это была самая популярная служба доступа к удаленным данным в Интернете и корпоративных IP-сетях. Первые спецификации FTP относятся к 1971 году. Серверы и клиенты FTP име­ются практически в каждой ОС семейства.UNIX, а также во многих других сетевых ОС. Клиенты FTP встроены сегодня в программы просмотра (браузеры) Интернета, так как архивы файлов на основе протокола FTP по-прежнему попу­лярны и для доступа к таким архивам браузером используется протокол FTP.

Протокол FTP позволяет целиком переместить файл с удаленного компьютера на локальный и наоборот, то есть работает по схеме загрузки-выгрузки. Кроме того, он поддерживает несколько команд просмотра удаленного каталога и пе­ремещения по каталогам удаленной файловой системы. Поэтому FTP особенно удобно использовать для доступа к тем файлам, данные которых нет смысла про­сматривать удаленно, а гораздо эффективней целиком переместить на клиент­ский компьютер (например, файлы исполняемых модулей приложений).

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

Протокол FTP выполнен по схеме клиент-сервер. Клиент FTP состоит из не­скольких функциональных модулей:

□ User Interface — пользовательский интерфейс, принимающий от пользовате­ля символьные команды и отображающий состояние сеанса FTP на символь­ном экране.

□ User-PI — интерпретатор команд пользователя. Этот модуль взаимодействует с соответствующим модулем сервера FTP.

□ User-DTP — модуль, осуществляющий передачу данных файла по командам, получаемым от модуля User-PI по протоколу клиент-сервер. Этот модуль взаи­модействует с локальной файловой системой клиента..

FTP-сервер включает следующие модули:

□ Server-PI — модуль, который принимает и интерпретирует команды, переда­ваемые по сети модулем User-PI.

□ Server-DTP — модуль, управляющий передачей данных файла по командам от модуля Server-PI. Взаимодействует с локальной файловой системой сервера.

Клиент и сервер FTP поддерживают параллельно два сеанса — управляющий се­анс и сеанс передачи данных. Управляющий сеанс открывается при установле­нии первоначального FTP-соединения клиента с сервером, причем в течение одного управляющего сеанса может последовательно выполняться несколько се­ансов передачи данных, в рамках которых передаются или принимаются не­сколько файлов.

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

1. Сервер FTP всегда открывает управляющий порт TCP 21 для прослушива­ния, ожидая приход запроса на установление управляющего сеанса FTP от удаленного клиента.

2. Посде установления управляющего соединения клиент отправляет на сервер команды, которые уточняют параметры соединения:

· имя и пароль клиента;

· роль участников соединения (активная или пассивная);

· порт передачи данных;

· тип передачи;

· тип передаваемых данных (двоичные данные или ASCII-код);

· директивы на выполнение действий (читать файл, писать файл, удалить файл и т. п.).

3. После согласования параметров пассивный участник соединения переходит в режим ожидания открытия соединения на порт передачи данных. Активный участник инициирует это соединение и начинает передачу данных.

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

Порты передачи данных выбирает клиент FTP (по умолчанию клиент может ис­пользовать для передачи данных порт управляющего сеанса), а сервер должен использовать порт, на единицу меньший порта клиента.

Протокол FTP использует при взаимодействии клиента с сервером несколько команд (не следует их путать с командами пользовательского интерфейса клиен­та, которые использует человек).

Эти команды делятся на три группы:

□ команды управления доступом к системе;

□ команды управления потоком данных;

□ команды службы FTP.

В набор команд управления доступом входят следующие команды:

□ USER — доставляет серверу имя клиента. Эта команда открывает управляю­
щий сеанс и может также передаваться при открытом управляющем сеансе
для смены имени пользователя.

□ PASS — передает в открытом виде пароль пользователя.

□ CWD — изменяет текущий каталог на сервере.

□ REIN — повторно инициализирует управляющий сеанс.

□ QUIT — завершает управляющий сеанс.

Команды управления потоком устанавливают параметры передачи данных:

□ PORT — определяет адрес и порт хоста, который будет активным участником соединения при передаче данных. Например, команда PORT 194,85,135,126.7,205 назначает активным участником хост 194.85.135.126 и порт 1997 (вычисление номера порта не тривиально, но вполне однозначно).

□ PASV — назначает хост пассивным участником соединения по передаче данных. В ответ на эту команду должна быть передана команда PORT с указанием адреса и порта, находящегося в режиме ожидания.

□ TYPE — задает тип передаваемых данных (ASCII-код или двоичные данные).

□ STRU — определяет структуру передаваемых данных (файл, запись, страница).

□ MODE — задает режим передачи (потоком, блоками и т. п.).

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

Команды службы FTP инициируют действия по передаче файлов или просмотру
удаленного каталога: '

□ RETR — запрашивает передачу файла от сервера на клиентский хост. Парамет­рами команды является имя файла. Может быть задано также смещение от начала файла — это позволяет начать передачу файла с определенного места при непредвиденном разрыве соединения (этот параметр используется в ко­манде reget пользовательского интерфейса).

□ ST0R — инициирует передачу файла от клиента на сервер. Параметры анало­гичны команде RETR.

□ RNFR и RNT0 — команды переименования удаленного файла. Первая в качестве аргумента получает старое имя файла, а вторая — новое.

□ DELE, MKD, RMD, LIST — эти команды соответственно удаляют файл, создают ката­лог, удаляют каталог и передают список файлов текущего каталога.

Каждая команда протокола FTP передается в текстовом виде по одной команде в строке. Строка заканчивается символами CR и LF ASCII-кода.

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

Символьные клиенты обычно поддерживают следующий основной набор команд:

□ open имя_хоста — открытие сеанса с удаленным сервером.

□ bye — завершение сеанса с удаленным хостом и завершение работы утилиты ftp.

□ close — завершение сеанса с удаленным хостом, утилита ftp продолжает рабо­тать.

□ ls (di г) — печать содержимого текущего удаленного каталога.

□ get имя_файла — копирование удаленного файла на локальный хост.

□ put имя_файла — копирование удаленного файла на удаленный сервер.

Файловая система NFS

Файловая система NFS (Network File System) создана компанией Sun Microsys­tems. В настоящее время это стандартная сетевая файловая система для ОС се­мейства UNIX, кроме того, клиенты и серверы NFS реализованы для многих других ОС. Принципы ее организации на сегодня стандартизованы сообществом Интернета, люследняя версия NFS v.4 описывается спецификацией RFC 3010, выпущенной в декабре 2000 года.

NFS представляет собой систему, поддерживающую схему удаленного доступа к файлам. Работа пользователя с удаленными файлами после выполнения опе­рации монтирования становится полностью прозрачной — поддерево файловой системы сервера NFS становится поддеревом локальной файловой системы.

Одной из целей разработчиков NFS была поддержка неоднородных систем с кли­ентами и серверами, работающими под управлением различных ОС на различ­ной аппаратной платформе. Этой цели способствует реализация NFS на основе механизма Sun RPC, поддерживающего по умолчанию средства XDR для уни­фицированного представления аргументов удаленных процедур.

Для обеспечения устойчивости клиентов к отказам серверов в NFS принят под­ход stateless, то есть серверы при работе с файлами не хранят данных об откры­тых клиентами файлах.

Основная идея NFS — позволить произвольной группе пользователей разделять общую файловую систему. Чаще всего все пользователи принадлежат одной ло­кальной сети, но не обязательно. Можно выполнять NFS и на глобальной сети. Каждый NFS-сервер предоставляет один или более своих каталогов для досту­па удаленным клиентам. Каталог объявляется доступным со всеми своими под­каталогами. Список каталогов, которые сервер передает, содержится в файле /etc/exports, так что эти каталоги экспортируются сразу автоматически при за­грузке сервера. Клиенты получают доступ к экспортируемым каталогам путем монтирования. Многие рабочие станции Sun бездисковые, но и в этом случае можно монтировать удаленную файловую систему к корневому каталогу, при этом вся файловая система целиком располагается на сервере. Выполнение про­грамм почти не зависит от того, где расположен файл: локально или на удален­ном диске. Если два или более клиента одновременно смонтировали один и тот же каталог, то они могут связываться путем разделения файла.

В своей работе файловая система NFS использует два протокола.

Первый NFS-протокол управляет монтированием! Клиент посылает серверу пол­ное имя каталога и запрашивает разрешение на монтирование этого каталога в какую-либо точку собственного дерева каталогов. При этом серверу не указыва­ется, в какое место будет монтироваться каталог сервера. Получив имя, сервер проверяет законность этого запроса и возвращает клиенту дескриптор файла, яв­ляющегося удаленной точкой монтирования. Дескриптор включает описатель типа файловой системы, номер диска, номер индексного дескриптора (inode) ка­талога, который является удаленной точкой монтирования, информацию без­опасности. Операции чтения и записи файлов из монтируемых файловых систем используют дескрипторы файлов вместо символьного имени.

Монтирование может выполняться автоматически, с помощью командных фай­лов при загрузке. Существует другой вариант автоматического монтирования: при загрузке ОС на рабочей станции удаленная файловая система не монтирует­ся, но при первом открытии удаленного файла ОС посылает запросы каждому серверу и после обнаружения этого файла монтирует каталог того сервера, на ко­тором расположен найденный файл.

Второй NFS-протокол используется для доступа к удаленным файлам и катало­гам. Клиенты могут послать запрос серверу для выполнения какого-либо дейст­вия над каталогом или операции чтения или записи файла. Кроме того, они могут запросить атрибуты файла, такие как тип, размер, время создания и моди­фикации. NFS поддерживается большая часть системных вызовов UNIX, за ис­ключением open и close. Исключение open и close не случайно. Вместо операции открытия удаленного файла клиент посылает серверу сообщение, содержащее имя файла, с запросом отыскать его (lookup) и вернуть дескриптор файла. В отличие от вызова open вызов lookup не копирует никакой информации во внутренние системные таблицы/Вызов read содержит дескриптор того файла, который нуж­но читать, смещение в уже читаемом файле и количество байт,, которые нужно прочитать. Преимуществом такой схемы является то, что сервер не запоминает ничего об открытых файлах. Таким образом, если сервер откажет, а затем будет восстановлен, информация об открытых файлах не потеряется, потому что она не поддерживается.

При отказе сервера клиент просто продолжает посылать на него команды чтения или записи в файлы, однако не получив ответа и исчерпав тайм-аут, клиент по­вторяет свои запросы. После перезагрузки сервер получает очередной повтор­ный запрос клиента и отвечает на него. Таки образом, крах сервера вызывает только некоторую паузу в обслуживании клиентов, но никаких дополнительных действий по восстановлению соединений и повторному открытию файлов от кли­ентов не требуется.

К сожалению, NFS затрудняет блокировку файлов. Во многих ОС файл может быть открыт и заблокирован так, чтобы другие процессы не имели к нему досту­па. Когда файл закрывается, блокировка снимается. В системах stateless, подоб­ных NFS, блокирование не может быть связано с открытием файла, так как сервер не знает, какой файл открыт. Следовательно, NFS требует специальных дополнительных средств управления блокированием.

В NFS используется кэширование на стороне клиента, данные в кэш переносят­ся поблочно и применяется упреждающее чтение, при котором чтение блока в кэш по требованию приложения всегда сопровождается чтением следующего блока по инициативе системы. Метод кэширования NFS не сохраняет семантику UNIX для разделения файлов. Вместо этого используется не раз подвергавшаяся кри­тике семантика, при которой изменения данных в кэшируемом клиентом файле видны другому клиенту, в зависимости от временных соотношений. Клиент при очередном открытии файла, имеющегося в его кэше, проверяет у сервера, когда файл был в последний раз модифицирован. Если это произошло после того, как файл был помещен в кэш, файл удаляется из кэша и от сервера получается новая копия файла. Клиенты распространяют модификации, сделанные в кэше, с пе­риодом в 30 секунд, так что сервер может получить обновления с большой за­держкой. В результате работы механизмов удаления данных из кэша и распро­странения модификаций данные, получаемые каким-либо клиентом, не всегда являются самыми свежими.

Репликация в NFS не поддерживается.

Служба каталогов