Network File System (NFS), возможно, является наиболее видной сетевой услугой, использующей RPC. Она позволяет обращаться к файлам на удаленных хостах точно тем же самым способом, как к любым локальным файлам. Это стало возможным за счет взаимодействия функциональных возможностей ядра на клиентской стороне (которая использует удаленную файловую систему) и NFS-сервера на серверной стороне (который обеспечивает доступ к данным). Этот доступ к файлу полностью прозрачен для клиента и работает через все разнообразие серверов и архитектуры хостов.
NFS предлагает ряд преимуществ:
Данные, к которым обращаются все пользователи, могут быть сохранены на центральном хосте, клиенты будут монтировать этот каталог при начальной загрузке. Например,
Вы можете сохранить все логины пользователей на одном хосте, настроить все хосты Вашей сети на монтирование каталога /home с этого хоста. Если все это установлено в паре с NIS, то пользователи смогут войти в любую систему и работать на одном множестве файлов.
Данные, потребляющие большие количества дискового пространства, могут быть сохранены на единственном хосте. Например, все файлы и программы, относящиеся к LaTeX и METAFONT могут быть сохранены и поддерживаться в одном месте. Мало того, что удобно ими управлять, так еще и место экономится.
Административно-управленческая информация может быть сохранена на одном хосте.
Нет нужды использовать rcp для того, чтобы установить один и тот же файл на 20 различных машинах.
Linux NFS в значительной степени работа Rick Sladkey, написавшего код NFS kernel и большие части NFS-сервера. Последний был создан из unfsd, NFS-сервер уровня пользователя, первоначально написанного Mark Shand, и hnfs Harris NFS-сервера, написанного Donald Becker.
Давайте теперь посмотрим, как NFS работает: клиент может запросить смонтировать каталог с удаленного хоста в локальный каталоге тем же способом, как он может установить физическое устройство. Однако, синтаксис, используемый для этого, несколько иной. Например, чтобы смонтировать каталог /home с хоста vlager в каталог /users на машине vale, администратор использовал бы следующую команду на vale:
# mount -t nfs vlager:/home /users
Команда mount попробует соединиться с rpc.mountd, daemon монтирования на vlager через RPC. Сервер проверит, разрешается ли vale смонтировать каталог, и если все нормально, вернет file handle. Этот handle будет использоваться во всех последовательных запросах к подкаталогам /users.
Когда кто-то обращается к файлу по NFS, kernel RPC-сайта вызовет rpc.nfsd (NFS daemon) на машине сервера. Это обращение берет handle файла, имя файла, к которому обращаются, идентификаторы группы и пользователя как параметры. Они используются в определении прав доступа к точно определенному файлу. Чтобы защититься от несанкционированного чтения или модифицирования файла, идентификаторы пользователя и группы должны быть одними и теми же на обоих хостах.
В большинстве реализаций UNIX®, функциональные возможности NFS клиента и сервера выполнены как демоны kernel-уровня, которые запускаются из пространства пользователя при начальной загрузке системы. Это NFS Daemon (rpc.nfsd) на хосте сервера и Block I/O Daemon (biod) на клиентском хосте. Чтобы улучшить производительность, biod выполняет асинхронный ввод-вывод, используя упреждающее чтение и отложенную запись. К тому же, несколько демонов rpc.nfsd обычно запускаются совместно.
Реализация NFS в Linux немного отличается в клиентском коде: она объединена с файловой системой VFS на уровне ядра и не требует дополнительного управления. Обычно код сервера запускается полностью в пространстве пользователя, так что управление несколькими копиями затруднено. Текущая реализация rpc.nfsd предлагает экспериментальную ограниченную поддержку нескольких серверов. Olaf Kirch разработал NFS-сервер уровня ядра, который появился в ядрах Linux 2.2 и выше. Эффективность заметно выросла. Позже мы поговорим об этом отдельно.
