3.2.1 Das NFS-Protokoll und der RPC

Im OSI-Schichtenmodell ist NFS der Anwendungsschicht sieben zuzuordnen. Es basiert auf dem von Sun eigens für NFS entwickelten Remote-Procedure-Call (RPC Version 2), der in [Sun88] standardisiert ist. Obwohl für NFS kein Transportprotokoll vorgeschrieben wurde, wird in der Praxis aus Performancegründen praktisch immer UDP verwendet. Der RPC benutzt für die Datenrepräsentation das Format XDR [Sun87], welches logisch auf der Präsentationsschicht sechs angesiedelt wird. In Abbildung 3.2 ist die NFS-Protokollschichtung nochmals zusammengefaßt.

 

Abbildung 3.2:  Protokollschichtung bei NFS

9#9

Der RPC arbeitet exakt nach dem in Abschnitt 3.1 beschriebenen Client/Server-Prinzip. Über den RPC-Mechanismus kann ein Client Aufträge an den Server senden. Ein Auftrag setzt sich aus dem Aufruf einer vom Server angebotenen Operation mit aktuellen Parametern und dem Rücksenden des Ergebnisses zusammen. In RPC-Terminologie ist ein Netzdienst ein RPC-Programm, bestehend aus einer Menge vom Server implementierter Prozeduren (Operationen). Jedem Dienst wird durch die Datei /etc/rpc eine eindeutige Programmnummer zugeordnet. Analog besitzen die Prozeduren eines Dienstes eine eindeutige Prozedurnummer und außerdem eine Versionsnummer. Ein Auftrag eines Clients trägt im RPC-Header die Programm-, Prozedur- und Versionsnummer, um die aufzurufende Operation genau zu spezifizieren.

Ein NFS-Server implementiert 18 verschiedene Operationen für den Zugriff auf ein Dateisystem. Die wichtigsten sind das Lesen und Schreiben von Dateiblöcken und Dateiattributen sowie das Anlegen und Löschen von Dateien. Der NFS-Server arbeitet bezüglich einer Folge von Client-Aufträgen zustandslos. Das bedeutet, daß jeder Auftrag die auszuführende Lese- oder Schreiboperation komplett beschreiben muß. Es werden keine Informationen zu geöffneten Dateien oder Zeiger für die Schreib- und Leseposition innerhalb einer Datei im Server gehalten. Ein Auftrag ist daher mit dem Absenden der Antwort an den Client, auf welche dieser synchron wartet, vollständig abgeschlossen. Die Zustandslosigkeit hat mehrere Vorteile. Nach einem Systemabsturz kann der NFS-Server einfach wieder gestartet werden, ohne daß der Zustand vor dem Absturz wiederhergestellt werden muß. Die Clients bemerken außer einem temporären Ausfall des Dienstes keine Veränderung. Weiterhin kann der zustandslose Datagrammdienst UDP mit seinem geringen Protokoll-Overhead eingesetzt werden. Hierdurch wird die maximale Datenmenge für Lese- oder Schreiboperation allerdings auf 8192 Bytes pro Auftrag begrenzt. Da die meisten NFS-Operationen idempotent sind, kann der Client bei Verlust des Anforderungs- bzw. Antwortpakets den Auftrag, sobald ein Timeout beim Warten auf die Antwort aufgetreten ist, einfach wiederholen. Für nicht idempotente Operationen wie das Löschen einer Datei unterhält der Server einen Cache für die zuletzt ausgeführten Operationen. Der Server kann Duplikate von Aufträgen daher erkennen und verwerfen.

Da NFS zustandslos arbeitet, sind Systemaufrufe wie open() und close() zum Öffnen und Schließen von Dateien auf NFS-Dateisystemen nicht sinnvoll und auch nicht implementiert. Damit Anwendungen aber transparent auf Dateien unterschiedlicher Dateisysteme zugreifen können, arbeiten die Systemaufrufe auf einer vom Filesystem unabhängigen Schicht. Die Systemaufrufe werden im Kernel vom virtuellen Filesystem (VFS) bearbeitet und je nach Zieldateisystem in spezifische, vom Filesystem abhängige Operationen übersetzt. Ein Leseaufruf read() wird bei einer lokalen Datei direkt an den Gerätetreiber weitergeleitet, bei einer Datei auf einem NFS-Dateisystem hingegen dem NFS-Client-Code übergeben, der einen entsprechenden RPC auf dem NFS-Server veranlaßt. Abbildung 3.3 verdeutlicht dieses Konzept.

 

Abbildung 3.3:  Integration von NFS in den Client-Kernel

10#10