3.2.2 Die Prozesse des NFS-Servers und Clients

• Server

  nfsd:

  Ein NFS-Server wird durch den Hintergrundprozeß (Dämon) nfsd implementiert. Dieser Prozeß empfängt die Aufträge der Clients und führt die Operationen auf dem lokalen Dateisystem aus. Die Bedienzeit des Auftrags ist abhängig von der Dauer der zugrundeliegenden Dateioperation und liegt in der Regel im Bereich einiger 10ms. Da der nfsd während der Dateioperation durch das System blockiert ist, kann er Aufträge nur streng seriell bearbeiten. Um den Durchsatz des NFS-Dienstes zu steigern, werden normalerweise mehrere gleichartige Serverprozesse (nfsd) gestartet. Somit können mehrere NFS-Anforderungen gleichzeitig bearbeitet werden. Der eigentliche Code des NFS-Server befindet sich wiederum aus Performancegründen im Kernel. Die nfsd-Benutzerprozesse sind im Prinzip also nur leere Hülsen für den Scheduler, um ein Multitasking innerhalb des NFS-Dienstes zu ermöglichen. Unter AIX 4.2.0 werden mehrere NFS-Serverprozesse durch Threads innerhalb des Kernels realisiert. In diesem Fall gibt es nur noch einen NFS-Benutzerprozeß nfsd. Die Serverprozesse besitzen keine eigenen Warteschlangen für Aufträge. Alle Serverprozesse binden sich an den gleichen Socket. Trifft ein neuer Auftrag ein, wird ein schlafender Serverprozeß vom Scheduler aufgeweckt, der den Auftrag übernimmt. Sind alle NFS-Serverprozesse beschäftigt, kann eine begrenzte Anzahl von Aufträgen in dem Socketpuffer gesammelt werden.

  rpc.mountd:

  Dieser Prozeß gehört ebenfalls zum NFS-Server. Damit ein Client auf ein von einem Server bereitgestelltes Dateisystem zugreifen kann, muß es dieses mittels eines mount-Kommandos in seinen lokalen Dateisystembaum einhängen. Ein mount auf einem NFS-Dateisystem führt zu einem RPC auf dem rpc.mountd des Servers. Dieser kontrolliert, ob der Client berechtigt ist, auf das Dateisystem des Servers zuzugreifen. Ist dies der Fall, übergibt er dem Client ein sog. handle, welches der Client für zukünftige Dateioperationen als Parameter benötigt. Durch diese Aktion gehen Client und Server die Dienstbeziehung ein. Von nun an kann der Client den Dienst, also ein konkretes NFS-Dateisystem nutzen. Der rpc.mountd implementiert ein eigenes RPC-Programm mit eigener RPC-Dienstnummer.

  portmapper:

  Dieser Prozeß wird nicht nur für den NFS-Dienst, sondern für alle RPC-basierten Dienste benötigt. Es gibt i.a. keine feste Zuordnung zwischen RPC-Programmen und den Kommunikations-Ports, an denen die zugehörigen Server ihren Dienst anbieten. Damit ein Client einen Dienst nutzen kann, muß ihm aber neben der IP-Adresse des Servers auch der UDP- oder TCP-Port des Dienstes bekannt sein. Der Portmapper unterhält einen Verzeichnisdienst, der RPC-Programmnummern in Portnummern auflöst. Möchte ein Client einen RPC-basierten Dienst nutzen, sendet er eine Anfrage mit der entsprechenden Dienstnummer an den Portmapper des Serverrechners. Dieser gibt als Antwort den zugehörigen UDP- oder TCP-Port zurück, falls ein Server für den angegebenen Dienst auf diesem Rechner existiert. Hierfür muß ein Server den ihm vom Betriebssystem bei Start des Dienstes zugewiesenen Port beim Portmapper registrieren. Der Portmapper selbst bietet seinen Dienst immer an dem well known Port 111 (UDP/TCP) an.

• Client

  biod:

  Beim Zugriff einer Anwendung auf eine Datei eines NFS-Dateisystems wird ein RPC-Request für den zugehörigen Server erstellt. Bei kleinen Dateioperationen wie Lesen oder Schreiben von Dateiattributen wird die Leistung der Anwendung durch das Blockieren beim Warten auf die Auftragserfüllung kaum beeinträchtigt. Anders verhält es sich, wenn große Datenmengen gelesen oder geschrieben werden müssen. Solche Dateioperationen werden unter UNIX über einen Puffer im Speicher (file buffer cache) abgewickelt. Die Pufferverwaltung sorgt beim Lesen durch vorzeitiges Laden (prefetching) von Dateiblöcken dafür, daß der Puffer immer gefüllt ist. Umgekehrt werden Schreiboperationen solange verzögert (delayed write), bis neuer Platz im Puffer benötigt wird. Dieser Mechanismus kann auch bei Lese- und Schreiboperationen auf NFS-Dateisystemen eingesetzt werden, wenn mehrere gleichartige biod-Prozesse auf dem System laufen. Diese Prozesse können für die Pufferverwaltung gleichzeitig mehrere Lese- oder Schreibaufträge mit maximaler Datenmenge (8 Kilobytes) an den NFS-Server stellen. Ein Client kann auch ohne biod-Prozesse betrieben werden. Dann muß aber mit einem sehr geringen Durchsatz beim Lesen und Schreiben gerechnet werden. Wie beim nfsd befindet sich der Code des biod im Kernel. Die Benutzerprozesse werden wiederum nur für das Scheduling benötigt.

• Client und Server

  rpc.lockd und rpc.statd:

  Diese beiden Prozesse müssen sowohl auf dem Client wie auch auf dem Server vorhanden sein. Hiermit werden Dateisperren (locks) auf NFS-Dateisystemen realisiert. Da Dateisperren das zustandslose Arbeitsprinzip eines NFS-Servers verletzen, sind für ihre Verwaltung eigene Hintergrundprozesse nötig. Auf den komplizierten Mechanismus wird an dieser Stelle nicht weiter eingegangen.