Сетевая файловая система (NFS)
NFS, the network file system, является возможно наиболее видной сетью услуг, использующей RPC. Это позволяет обращаться к файлам на отдаленных хостах точно тем же самым способом, как пользователь обратился бы к любым" локальным файлам. Сделано возможным смешением kernel функциональных возможностей на клиентской стороне (которая использует отдаленную файловую систему) и NFS сервер на стороне сервера (который обеспечивает файл данных). Этот доступ к файлу полностью очевиден клиенту, и работает через все разнообразие серверов и архитектуры хостов.
NFS предлагает ряд преимуществ:
+ Данные, к которым обращаются все пользователи, могут быть сохранены на центральном хосте, с клиенами устанавливающими этот каталог при начальной загрузке. Например, Вы можете сохранить все accounts пользователей на одном хосте, и иметь все хосты на Вашем сетевом mount /home от того хоста. Если оно установлено бок о бок с NIS, то пользователи могут затем войти в любую систему, и все еще работать на одном множестве файлов.
+ Данные, потребляющие большие количества дискового пространства могут быть сохранены в единственном хосте. Например, все файлы и программы относящиеся к LaTeX и METAFONT могут быть сохранены и поддерживаться в одном месте.
+ Административно-управленческая информация может быть сохранена в адинственном хосте. Нет нужды использовать rcp для того, чтобы установить тот же самый глупый файл на 20 различных машин.
Linux NFS - в значительной степени работа Rick Sladkey, (1), кто написал NFS kernel код и большие части NFS сервера. Последний, выводил из unfsd пространства пользователя NFS сервер, первоначально написанный Mark Shand, и hnfs Harris NFS сервер, написанный Donald Becker.
Давайте теперь посмотрим том, как NFS работает: клиент может запросить установить каталог от отдаленного хоста на локальном каталоге тем же способом, и он может установить физическое устройство. Однако, синтаксис, используемый для того, чтобы точно определить отличен ли отдаленный каталог. Например, чтобы mount /home хост vlager к /users на vale, администратор выпустил бы следующую команду на vale: (2) " 1. Rick может быть найден в jrs@world.std.com.
# mount -t nfs vlager:/home /users
mount затем попробует соединиться с mountd, устанавленный с daemon на vlager через RPC. Сервер проверит, разрешается ли vale повысить каталог, и если так, вернет это к file handle. Этот handle файл будет использоваться во всех последовательных запросах к картотекам ниже /users.
Когда кто -то обращается к файлу над NFS, kernel места RPC вызовут nfsd (NFS daemon) на машине сервера. Это обращение берет handle файл, имя файла, к которому обращаются, и user's user и идентичность группы как параметры. Они используются в определении прав доступа к точно определенному файлу. Чтобы предотвратить от несанкционированного чтения или модифицирования файла, пользователь и идентичность группы должны быть теме же самыми на обоих хостах.
На большинстве Un*x реализаций, NFS функциональные возможности обоих клиентов и сервер выполнены как kernel уровень daemons, которые начаты из пространства пользователя при начальной загрузке системы. Они - NFS daemon (nfsd) на хосте сервера, и блок ввода - вывода Daemon (biod) выполняющийся на клиентском хосте. Чтобы улучшить производительность, biod выполняет асинхронный ввод - вывод, используя чтение - вперед и запись-назад; также, несколько nfsd daemons обычно запускается совместно.
NFS реализация Linux, немного отлична в этом самом клиентском коде, крепко объединена в файловой системе (VFS) уровень ядра и не требует дополнительного управления через biod. С другой стороны код сервера запускается полностью в пространстве пользователя, так, чтобы при запуске нескольких копий сервера в одно и то же время было бы почти невозможным из- за синхронизации. Linux NFS, в настоящее время также существует отсутствие чтения - вперед и записи-назад, но Rick Sladkey планирует исправит этот недостатолк в ближайшее время. (3)
Самая гольъая проблема с Linux NFS кодом - то, что Linux kernel версии 1.0 не способен распределить память в кусках больших чем 4k; как следствие, сетевой код не может обрабатывать датаграммы большие чем приблизительно 3500 байтов после вычитания размера заголовка и т.д. Это значит, что передача к и из NFS daemons выполняющейся на системах, которые используют большие UDP датаграммы по умолчанию (например 8k на SunOS) должны быть уменьшенны в размере искуственно. Этот причиняет вред характеристике под влиянием некоторых обстоятельств. (4) Этот предел входит в поздние Linux-1.1 ядра, и клиентский код был модифицирован для того, чтобы пользоваться этим преимуществом.
2. Заметьте, что Вы можете опустить -t nfs аргумент, потому что mount видит из двоеточия то, что это определяет NFS объем. 3. Задача с write-behind - то, что kernel буфер кэша индексирован парами device/inode, и следовательно не может использоваться для nfs- установленных файловых систем.
