NFS modern: NFSv4, pNFS und Co.

Schon in den 80er Jahren des letzten Jahrhunderts machten sich findige Ingenieure bei Sun an die Arbeit, Dateien zentral auf einem Server abzulegen, die dann von vielen Clients genutzt werden konnten. Mit der Veröffentlichung als RFC 1094 [1] im März 1989 setzten sie die Versionsnummer auf 2 herauf, um sich von den internen Tests bei Sun zu unterscheiden.

NFS in Version 2

Zentrales Problem von Dateisystemen, auf die viele Benutzer zugreifen können, ist natürlich, ein mögliches Chaos durch gleichzeitiges Schreiben zu verhindern. Was passiert, wenn ein Benutzer eine Datei bearbeitet und ein anderer Benutzer diese Datei zur selben Zeit löscht oder eigene Änderungen einfügt? Dieses Problem tritt nicht erst mit modernen Cluster-Dateisystemen oder einer verteilten Versionsverwaltung auf. Die Lösung für NFS war ein Locking- System. Ein eigener Dienst kümmert sich auf dem Server darum, benutzte Dateien für andere zu sperren.

Die Ingenieure wollten NFS so einfach wie möglich implementieren und verteilten die einzelnen Komponenten deshalb auf einzelne Dienste. Alle Dienste laufen als eigenständige Prozesse, die sich über Remote Procedure Calls (RPCs, [2]) aufrufen lassen. Diese Prozesse gibt es:

• nfs: Der zentrale NFS-Dienst mit den zugehörigen RPCs, der sich um die Anfragen von Clients nach Dateien kümmert.
• nfslock: Die Aufgabe dieses Dienstes ist es, Dateien für einzelne Clients zu reservieren und ein Veto einzulegen, wenn ein weiterer Client auf die Datei zugreifen will.
• portmapper: Der Dienst führt Buch über die RPC-Programmnummern und Nutzung der IP-Ports auf einem System. Alle Dienste melden sich beim portmapper an und bekommen einen Port zugewiesen. Auf Nachfrage liefert der portmapper auch den Zugang zu einem Dienst. Mit der Einführung von IPv6 wurde der portmapper duch rpcbind abgelöst.
• rpcbind ist die moderne Version des portmappers, der auch IPv6 versteht.

Die nachfolgenden Dienste werden durch einzelne Programme erbracht, die im Hintergrund arbeiten und sich dabei am zentralen RPC-Dienst anmelden:

• rpc.mountd ist für die Mount-Anfragen eines Clients zuständig. Er überprüft die Rechtmäßigkeit der Anfrage und liefert dem Client gegebenenfalls das Filehandle für den Zugriff auf die Daten.
• rpc.nfs ist der Dienste-Teil des NFS-Servers im Kernel.
• lockd läuft auf sowohl auf dem NFS-Server als auch auf den Clients und kümmert sich um den exklusiven Zugriff auf die Dateien.
• rpc.statd: Dieser Dienst eines NFS-Servers informiert die Clients darüber, dass ein NFS-Server neu gestartet wurde, nachdem er unsanft abgestürzt war. Die Clients können dann sofort ihre Locks erneuern und so verhindern, dass ein anderer Zugriff auf die Dateien erhält.
• rpc.quotad: Der Dienst ist dafür verantwortlich, dass kein Benutzer mehr Plattenplatz belegt, als ihm zusteht. Notfalls verweigert er das Speichern zu großer Dateien.

Der NFSv2-Server arbeitet ohne Status, deshalb nutzt er auch das Protokoll UDP für die Datenübertragung.

Da die Portnummern des RPC-Dienstes verteilt werden, variieren sie. Das führt zu besonderer Freude bei jedem Firewall-Administrator. Viele haben hier kapituliert und gleich alle Ports zwischen den Clients und dem Server freigeschaltet.

Die Version NFSv3

Mit den Erfahrungen aus Version 2 konnten die Macher des Internets (die Ingenieure der IETF) dazu übergehen, vieles zu verbessern. Im Jahr 1995 erschien RFC 1813 und NFSv3 war geboren. Die Grundstruktur aus Diensten, die sich beim zentralen RPC-Dienst registrieren, blieb erhalten. Daneben gab es aber viele Verbesserungen im Detail. Mit der Version 3 wurden 64-Bit-Dateisysteme unterstützt. Somit war auch der Zugriff auf Dateien mit mehr als 2 GByte endlich möglich.

Verschiedene Hersteller implementierten auch NFS über das Protokoll TCP in ihre Produkte. Mit dem TCP-Protokoll konnte NFS auch über WAN-Strecken mit erhöhten Latenzzeiten und Paketverlusten genutzt werden.