9.1.3 Интерфейс сетевой файловой службы
Для пользователей сети и сетевых приложений в основном интересен интерфейс, который предоставляет сетевая файловая служба, а не ее внутреннее устройство. Существует несколько типов интерфейсов сетевой файловой службы, которые отличаются несколькими ключевыми аспектами, рассматриваемыми в данном разделе.
Структура файла
Для любой файловой службы, независимо от того, централизована она или распределена, самым главным является вопрос, что такое файл? Во многих системах, таких как UNIX и Windows, файл — это не интерпретируемая последовательность байтов. Значение и структура информации в файле является заботой прикладных программ, операционную систему это не интересует. В ОС мэйнфреймов поддерживаются разные типы логической организации файлов, каждый с различными свойствами. Файл может быть организован как последовательность записей, и у операционной системы имеются вызовы, которые позволяют работать на уровне этих записей.
Большинство современных сетевых файловых систем поддерживают определение файла как последовательности байтов, а не последовательности записей, следуя примеру локальных файловых систем. Структура файла естественным образом отражается на типе сетевого файлового интерфейса, поддерживающего для неструктурированных файлов чтение любой области в файле, а для структурированных — только записей определенного формата.
Модифицируемость файлов
Важным аспектом файловой модели является возможность модификации файла после его создания. В большинстве сетевых файловых систем файлы могут модифицироваться, но в некоторых распределенных системах единственными операциями с файлами являются create (создать) и read (прочитать). Такие файлы называются неизменяемыми. Для неизменяемых файлов намного легче осуществить кэширование файла и его репликацию (тиражирование), так как исключаются все проблемы, связанные с обновлением всех копий файла при его изменении. В файловых системах, работающих с немодифицируемыми файлами, проблемы поддержки многочисленных версий файла, возникающих при его модификации, перекладываются на плечи пользователей, которые должны давать им имена, отражающие тот факт, что все множество файлов имеет близкое содержание, и в то же время позволяющие различать версии файлов.
Семайтика разделения файлов
Когда два или более пользователей разделяют один файл, необходимо точно определить семантику чтения и записи, чтобы избежать проблем с интерпретацией результирующих данных файла.
□ Семантика UNIX. В централизованных многопользовательских операционных системах, разрешающих разделение файлов, таких как UNIX (имеется в виду локальная версия этой ОС), обычно определяется, что когда операция чтения следует за операцией записи, то читается только что обновленный файл. Аналогично, когда операция чтения следует за двумя операциями записи, то читается файл, измененный последней операцией записи. Тем самым система придерживается абсолютного временного упорядочивания всех операций и всегда возвращает самое последнее значение данных. Если запись осуществляется в открытый многими пользователями файл, то все эти пользователи немедленно видят результат изменения данных файла. Обычно такая модель называется семантикой UNIX. В централизованной системе, где файлы хранятся в единственном экземпляре, ее легко и понять, и реализовать.
Семантика UNIX может быть обеспечена и в распределенных системах, но только если в ней имеется лишь один файловый сервер и клиенты не кэширу-ют файлы. Для этого все операции чтения и записи направляются на файловый сервер, который обрабатывает их строго последовательно. На практике, однако, производительность распределенной системы, в которой все запросы к файлам идут на один сервер, часто становится неудовлетворительной. Эта проблема иногда решается за счет разрешения клиентам обрабатывать локальные копии часто используемых файлов в своих личных кэшах. Если клиент сделает локальную копию файла в своем локальном кэше и начнет ее модифицировать, а вскоре после этого другой клиент прочитает этот файл с сервера, то он получит неверную копию файла. Одним из способов устранения этого недостатка является немедленный возврат всех изменений в кэшированном файле на сервер. Такой подход хотя и концептуально прост, но не эффективен. Распределенные файловые системы обычно используют более свободную семантику разделения файлов.
□ Сеансовая семантика. В соответствии с этой моделью изменения в открытом файле сначала видны только процессу, который модифицирует файл, и только после закрытия файла эти изменения могут видеть другие процессы. При использовании сеансовой семантики возникает проблема одновременного использования одного и того же файла двумя или более клиентами. Одним из решений этой проблемы является принятие правила, в соответствии с которым окончательным является тот вариант, который был закрыт последним. Однако из-за задержек в сети часто оказывается трудно определить, какая из копий файла была закрыта последней. Менее эффективным, но гораздо более простым в реализации является вариант, при котором окончательным результирующим файлом на сервере считается любой из этих файлов, то есть ре зультат операций над файлом не является детерминированным.
□ Семантика неизменяемых файлов. Следующий подход к разделению файлов заключается в том, чтобы сделать все файлы неизменяемыми. Тогда файл нельзя открыть для записи, а можно выполнять только операции create (создать) и read (читать). Тогда для изменения файла остается только возможность создать полностью новый файл и поместить его в каталог под новым именем. Следовательно, хотя файл и нельзя модифицировать, его можно заменить (автоматически) новым файлом. Таким образом, проблема, связанная с одновременным использованием файла, для файловой системы просто исчезнет, но с ней столкнутся пользователи, которые будут вынуждены вести учет имен своих копий модифицированного файла.
□ Транзакциопная семантика. Четвертый способ работы с разделяемыми файлами в распределенных системах — это использование механизма неделимых транзакций, достаточно подробно описанного в главе 8 «Дополнительные возможности файловых систем».
Контроль доступа
С каждым разделяемым файлом обычно связан список управления доступом (Access Control List, ACL), обеспечивающий защиту данных от несанкционированного доступа. В том случае, когда локальная файловая система поддерживает механизм ACL для файлов и каталогов при локальном доступе, сетевая файловая система использует этот механизм и при доступе по сети. Если же механизм защиты в локальной файловой системе отсутствует, то сетевой файловой системе приходится поддерживать его самостоятельно, иногда — упрощенным способом, защищая разделяемый каталог и входящие в него файлы и подкаталоги как единое целое. В Windows NT/2000 существуют два механизма защиты — на уровне разделяемых каталогов и на уровне локальных каталогов и файлов. Последний работает только в том случае, когда в качестве локальной файловой системы используется система NTFS, поддерживающая механизм ACL. Механизм защиты разделяемых каталогов нужен для того, чтобы защищать данные, хранящиеся в локальной файловой системе FAT, не имеющей механизмов защиты. В том случае, когда работают оба уровня защиты, у пользователей и администраторов могут иногда возникать некоторые логические сложности, связанные с определением реальных прав доступа как комбинации нескольких правил.
Единица доступа
Файловый интерфейс может быть отнесен к однму из двух типов в зависимости от того, поддерживает ли он модель загрузки-выгрузки или модель удаленного доступа. В модели загрузки-выгрузки пользователю предлагаются средства чтения или записи файла целиком. Эта модель предполагает следующую схему обработки файла: чтение файла с сервера на машину клиента, обработка файла на машине клиента и запись обновленного файла на сервер. Типичным представителем этого вида файлового интерфейса является служба FTP, пользователь которой должен применить команду get file_name для перемещения файла с сервера на клиентский компьютер и команду put file_name для возвращения файла на сервер.
Преимуществом этой модели является ее концептуальная простота. Кроме того, передача файла целиком очень эффективна в отношении объема создаваемого трафика. Главным недостатком этой модели являются высокие требования к объему диска клиента, который должен вместить любой файл, хранящийся на сервере. Кроме того, неэффективно перемещать весь файл, если нужна его небольшая часть. Недостатком многих реализаций такого интерфейса является отсутствие прозрачности операций с удаленными файлами, когда пользователь должен самостоятельно набирать команды перемещения файлов (как в службе FTP), хотя существуют реализации, выполняющие такую работу полностью самостоятельно при первом обращении к удаленному файлу (при этом, правда, необходимо решить вопрос, каким образом пользователь может задать обращение к удаленному файлу).
Другой тип файлового интерфейса соответствует модели удаленного доступа, которая предполагает поддержку большого количества операций над файлами: открытие и закрытие файлов, чтение и запись частей файла, позиционирование в файле, проверка и изменение атрибутов файла и т. д. В то время как в модели загрузки-выгрузки файловый сервер обеспечивал только хранение и перемещение файлов, в данном случае все файловые операции выполняются на серверах, а клиенты только генерируют запросы на их отработку. Преимуществом такого подхода являются низкие требования к дисковому пространству на клиентских машинах, а также исключение необходимости передачи целого файла, когда нужна только его часть. Модель удаленного доступа часто используется в прозрачных реализациях файлового интерфейса, когда удаленные файловые системы монтируются в общее с локальной системой дерево (или его часть, что происходит при отображении удаленной системы на букву логического диска).
Модели удаленного доступа могут использовать различные наименьшие единицы перемещения части файла. Наиболее популярны такие единицы, как байт, блок или запись. Последний вид единицы может применяться только в том случае, когда локальная файловая система поддерживает структурированные файлы.