1. Einführung (Introduction)

Das NFS-Protokoll (NFS Protocol) von Sun bietet transparenten Fernzugriff auf gemeinsam genutzte Dateisysteme über Netzwerke hinweg. Das NFS-Protokoll ist unabhängig von Maschine, Betriebssystem, Netzwerkarchitektur und Transportprotokoll konzipiert. Diese Unabhängigkeit wird durch die Verwendung von Remote Procedure Call (RPC) Primitiven erreicht, die auf einer externen Datenrepräsentation (eXternal Data Representation, XDR) aufbauen. Implementierungen des NFS Version 2 Protokolls existieren für eine Vielzahl von Maschinen, von Personalcomputern bis zu Supercomputern. Die ursprüngliche Version des NFS-Protokolls ist in der Network File System Protocol Specification [RFC1094] spezifiziert. Eine Beschreibung der ursprünglichen Implementierung findet sich in [Sandberg].

Das unterstützende MOUNT-Protokoll führt die betriebssystemspezifischen Funktionen aus, die es Clients ermöglichen, entfernte Verzeichnisbäume an einen Punkt im lokalen Dateisystem anzuhängen. Der Mount-Prozess ermöglicht es dem Server auch, über Exportkontrolle eingeschränkten Clients Fernzugriffsrechte zu gewähren.

Der Lock Manager bietet Unterstützung für Dateisperren bei Verwendung in der NFS-Umgebung. Das Network Lock Manager (NLM) Protokoll isoliert die inhärent zustandsbehafteten Aspekte der Dateisperrung in ein separates Protokoll.

Eine vollständige Beschreibung der oben genannten Protokolle und ihrer Implementierung findet sich in [X/OpenNFS].

Der Zweck dieses Dokuments ist:

• Das NFS Version 3 Protokoll zu spezifizieren.

• Die Semantik des Protokolls durch Annotation und Beschreibung der beabsichtigten Implementierung zu beschreiben.

• Das MOUNT Version 3 Protokoll zu spezifizieren.

• Die Änderungen zwischen dem NLM Version 3 Protokoll und dem NLM Version 4 Protokoll kurz zu beschreiben.

Der normative Text ist die Beschreibung der RPC-Prozeduren sowie der Argumente und Ergebnisse, die das Over-the-Wire-Protokoll und die Semantik dieser Prozeduren definieren. Das Material, das die Implementierungspraxis beschreibt, hilft beim Verständnis der Protokollspezifikation und beschreibt einige mögliche Implementierungsprobleme und Lösungen. Es ist nicht möglich, alle Implementierungen zu beschreiben, und die UNIX-Betriebssystem-Implementierung des NFS Version 3 Protokolls wird am häufigsten verwendet, um Beispiele zu liefern. Vor diesem Hintergrund hat die Implementierungsdiskussion nicht die Autorität der Beschreibung des Over-the-Wire-Protokolls selbst.

1.1 Umfang des NFS Version 3 Protokolls (Scope of the NFS version 3 protocol)

Diese Überarbeitung des NFS-Protokolls adressiert neue Anforderungen. Der Bedarf zur Unterstützung größerer Dateien und Dateisysteme hat Erweiterungen veranlasst, um 64-Bit-Dateigrößen und -Offsets zu ermöglichen. Die Überarbeitung verbessert die Sicherheit durch Hinzufügen der Unterstützung für eine Zugriffsprüfung, die auf dem Server durchgeführt wird. Leistungsmodifikationen sind von drei Arten:

1. Die Anzahl der Over-the-Wire-Pakete für eine gegebene Menge von Dateioperationen wird reduziert, indem bei jeder Operation Dateiattribute zurückgegeben werden, wodurch die Anzahl der Aufrufe zum Abrufen geänderter Attribute verringert wird.

2. Der Schreibdurchsatz-Engpass, der durch die synchrone Definition des Schreibens im NFS Version 2 Protokoll verursacht wurde, wurde behoben, indem Unterstützung hinzugefügt wurde, damit der NFS-Server unsichere Schreibvorgänge (unsafe writes) durchführen kann. Unsichere Schreibvorgänge sind Schreibvorgänge, die nicht auf stabilen Speicher festgeschrieben wurden, bevor die Operation zurückkehrt. Diese Spezifikation definiert eine Methode zum zuverlässigen Festschreiben dieser unsicheren Schreibvorgänge auf stabilen Speicher.

3. Beschränkungen der Übertragungsgrößen wurden gelockert.

Die Fähigkeit, mehrere Versionen eines Protokolls in RPC zu unterstützen, ermöglicht es Implementierern des NFS Version 3 Protokolls, Clients und Server zu definieren, die Rückwärtskompatibilität mit der bestehenden installierten Basis von NFS Version 2 Protokollimplementierungen bieten.

Die hier beschriebenen Erweiterungen repräsentieren eine Evolution des bestehenden NFS-Protokolls, und die meisten Designmerkmale des in [Sandberg] beschriebenen NFS-Protokolls bleiben bestehen. Siehe Änderungen gegenüber dem NFS Version 2 Protokoll auf Seite 11 für eine detailliertere Zusammenfassung der durch diese Überarbeitung eingeführten Änderungen.

1.2 Nützliche Begriffe (Useful terms)

In dieser Spezifikation ist ein "Server" eine Maschine, die dem Netzwerk Ressourcen zur Verfügung stellt; ein "Client" ist eine Maschine, die über das Netzwerk auf Ressourcen zugreift; ein "Benutzer (user)" ist eine Person, die auf einem Client angemeldet ist; eine "Anwendung (application)" ist ein Programm, das auf einem Client ausgeführt wird.

1.3 Remote Procedure Call

Die Sun Remote Procedure Call Spezifikation bietet eine prozedur-orientierte Schnittstelle zu entfernten Diensten. Jeder Server stellt ein Programm bereit, das eine Menge von Prozeduren ist. Der NFS-Dienst ist ein solches Programm. Die Kombination aus Host-Adresse, Programmnummer, Versionsnummer und Prozedurnummer spezifiziert eine entfernte Dienstprozedur. Server können mehrere Versionen eines Programms unterstützen, indem sie unterschiedliche Protokollversionsnummern verwenden.

Das NFS-Protokoll wurde so konzipiert, dass es kein spezifisches Zuverlässigkeitsniveau von seinen unteren Ebenen erfordert, sodass es potenziell auf vielen zugrunde liegenden Transportprotokollen verwendet werden kann. Der NFS-Dienst basiert auf RPC, das die Abstraktion über Netzwerk- und Transportprotokolle niedrigerer Ebenen bereitstellt.

Der Rest dieses Dokuments setzt voraus, dass die NFS-Umgebung auf Sun RPC implementiert ist, das in [RFC1057] spezifiziert ist. Eine vollständige Diskussion findet sich in [Corbin].

1.4 Externe Datenrepräsentation (External Data Representation)

Die eXternal Data Representation (XDR) Spezifikation bietet eine Standardmethode zur Darstellung einer Menge von Datentypen in einem Netzwerk. Dies löst das Problem unterschiedlicher Byte-Reihenfolgen, Strukturausrichtungen und Datentypdarstellungen auf verschiedenen kommunizierenden Maschinen.

In diesem Dokument wird die RPC Data Description Language verwendet, um die XDR-Formatparameter und -ergebnisse für jede der RPC-Dienstprozeduren zu spezifizieren, die ein NFS-Server bereitstellt. Die RPC Data Description Language ähnelt Deklarationen in der Programmiersprache C. Einige neue Konstrukte wurden hinzugefügt. Die Notation:

string  name[SIZE];
string  data<DSIZE>;

definiert name, das ein Block fester Größe von SIZE Bytes ist, und data, das ein Block variabler Größe von bis zu DSIZE Bytes ist. Diese Notation zeigt Arrays fester Länge und Arrays mit einer variablen Anzahl von Elementen bis zu einem festen Maximum an. Eine Definition variabler Länge ohne angegebene Größe bedeutet, dass es keine maximale Größe für das Feld gibt.

Die diskriminierte Union-Definition:

union example switch (enum status) {
     case OK:
        struct {
           filename      file1;
           filename      file2;
           integer       count;
        }
     case ERROR:
        struct {
           errstat       error;
           integer       errno;
        }
     default:
        void;
}

definiert eine Struktur, bei der das erste Element im Netzwerk ein Aufzählungstyp namens status ist. Wenn der Wert von status OK ist, wird das nächste Element im Netzwerk die Struktur sein, die file1, file2 und count enthält. Andernfalls, wenn der Wert von status ERROR ist, wird das nächste Element im Netzwerk eine Struktur sein, die error und errno enthält. Wenn der Wert von status weder OK noch ERROR ist, gibt es keine weiteren Daten in der Struktur.

Der XDR-Typ hyper ist eine 8-Byte (64-Bit) Größe. Er wird auf die gleiche Weise wie der Integer-Typ verwendet. Zum Beispiel:

hyper          foo;
unsigned hyper bar;

foo ist ein vorzeichenbehafteter 8-Byte-Wert, während bar ein vorzeichenloser 8-Byte-Wert ist.

Obwohl RPC/XDR-Compiler existieren, um Client- und Server-Stubs aus RPC Data Description Language-Eingaben zu generieren, erfordern NFS-Implementierungen deren Verwendung nicht. Jede Software, die eine äquivalente Codierung und Decodierung zur kanonischen Netzwerkreihenfolge von durch XDR definierten Daten bereitstellt, kann verwendet werden, um mit anderen NFS-Implementierungen zusammenzuarbeiten.

XDR wird in [RFC1014] beschrieben.

1.5 Authentifizierung und Berechtigungsprüfung (Authentication and Permission Checking)

Das RPC-Protokoll enthält bei jedem Aufruf einen Slot für Authentifizierungsparameter. Der Inhalt der Authentifizierungsparameter wird durch den Authentifizierungstyp bestimmt, den Server und Client verwenden. Ein Server kann mehrere verschiedene Authentifizierungs-Flavors gleichzeitig unterstützen. Der AUTH_NONE-Flavor bietet Null-Authentifizierung, das heißt, es werden keine Authentifizierungsinformationen übergeben. Der AUTH_UNIX-Flavor bietet UNIX-style Benutzer-ID, Gruppen-ID und Gruppen bei jedem Aufruf. Der AUTH_DES-Flavor bietet DES-verschlüsselte Authentifizierungsparameter basierend auf einem netzwerkweiten Namen, wobei Sitzungsschlüssel über ein Public-Key-Schema ausgetauscht werden. Der AUTH_KERB-Flavor bietet DES-verschlüsselte Authentifizierungsparameter basierend auf einem netzwerkweiten Namen, wobei Sitzungsschlüssel über Kerberos-Geheimnisschlüssel ausgetauscht werden.

Der NFS-Server prüft Berechtigungen, indem er die Anmeldeinformationen aus den RPC-Authentifizierungsinformationen in jeder entfernten Anfrage entnimmt. Zum Beispiel erhält der Server bei Verwendung des AUTH_UNIX-Authentifizierungs-Flavors bei jedem Aufruf die effektive Benutzer-ID, effektive Gruppen-ID und Gruppen des Benutzers und verwendet sie zur Zugriffsprüfung. Die Verwendung von Benutzer-IDs und Gruppen-IDs impliziert, dass Client und Server entweder die gleiche ID-Liste teilen oder lokales Benutzer- und Gruppen-ID-Mapping durchführen. Server und Clients müssen sich über das Mapping von Benutzer zu UID und von Gruppe zu GID einigen, für Sites, die keinen konsistenten Benutzer-ID- und Gruppen-ID-Raum implementieren. In der Praxis wird solches Mapping typischerweise auf dem Server durchgeführt, entweder nach einem statischen Mapping-Schema oder einem Mapping, das vom Benutzer von einem Client zum Zeitpunkt des Mountens eingerichtet wird.

Der AUTH_DES- und AUTH_KERB-Stil der Authentifizierung basiert auf einem netzwerkweiten Namen. Er bietet durch die Verwendung von DES-Verschlüsselung und öffentlichen Schlüsseln im Fall von AUTH_DES und DES-Verschlüsselung und Kerberos-Geheimnisschlüsseln (und Tickets) im Fall von AUTH_KERB größere Sicherheit. Wiederum müssen Server und Client über die Identität eines bestimmten Namens im Netzwerk übereinstimmen, aber das Name-zu-Identität-Mapping ist betriebssystemunabhängiger als das UID- und GID-Mapping in AUTH_UNIX. Da die Authentifizierungsparameter verschlüsselt sind, muss ein böswilliger Benutzer das Netzwerkkennwort oder den privaten Schlüssel eines anderen Benutzers kennen, um sich als dieser Benutzer auszugeben. Ebenso ist der vom Server zurückgegebene Verifizierer ebenfalls verschlüsselt, sodass das Vortäuschen eines Servers die Kenntnis eines Netzwerkkennworts erfordert.

Die NULL-Prozedur erfordert typischerweise keine Authentifizierung.

1.6 Philosophie (Philosophy)

Diese Spezifikation definiert das NFS Version 3 Protokoll, d.h. das Over-the-Wire-Protokoll, über das ein Client auf einen Server zugreift. Das Protokoll bietet eine wohldefinierte Schnittstelle zu den Dateiressourcen eines Servers. Ein Client oder Server implementiert das Protokoll und bietet ein Mapping der lokalen Dateisystemsemantik und -aktionen auf die im NFS Version 3 Protokoll definierten. Implementierungen können in unterschiedlichem Maße variieren, je nachdem, in welchem Umfang eine gegebene Umgebung alle im NFS Version 3 Protokoll definierten Operationen und Semantik unterstützen kann. Obwohl Implementierungen existieren und verwendet werden, um verschiedene Aspekte des NFS Version 3 Protokolls zu veranschaulichen, ist die Protokollspezifikation selbst die endgültige Beschreibung, wie Clients auf Serverressourcen zugreifen.

Da das NFS Version 3 Protokoll betriebssystemunabhängig konzipiert ist, entspricht es nicht notwendigerweise der Semantik eines bestehenden Systems. Von Serverimplementierungen wird erwartet, dass sie ihr Bestes tun, um das Protokoll zu unterstützen. Wenn ein Server eine bestimmte Protokollprozedur nicht unterstützen kann, kann er den Fehler NFS3ERR_NOTSUP zurückgeben, der anzeigt, dass die Operation nicht unterstützt wird. Zum Beispiel unterstützen viele Betriebssysteme das Konzept eines Hard Links nicht. Ein Server, der Hard Links nicht unterstützen kann, sollte als Antwort auf eine LINK-Anfrage NFS3ERR_NOTSUP zurückgeben. FSINFO beschreibt die am häufigsten nicht unterstützten Prozeduren in der Properties-Bitmap. Alternativ kann ein Server eine gegebene Operation nativ nicht unterstützen, sie aber in der NFS Version 3 Protokollimplementierung emulieren, um größere Funktionalität bereitzustellen.

In einigen Fällen kann ein Server die meiste der vom Protokoll beschriebenen Semantik unterstützen, aber nicht alle. Zum Beispiel gibt das ctime-Feld in der fattr-Struktur die Zeit an, zu der die Attribute einer Datei zuletzt geändert wurden. Viele Systeme halten diese Information nicht vor. In diesem Fall könnte ein Server, anstatt die GETATTR-Operation nicht zu unterstützen, sie simulieren, indem er die letzte Änderungszeit anstelle von ctime zurückgibt. Server müssen vorsichtig sein, wenn sie Attributinformationen simulieren, aufgrund möglicher Nebenwirkungen auf Clients. Zum Beispiel verwenden viele Clients Dateiänderungszeiten als Basis für ihr Cache-Konsistenzschema.

NFS-Server sind dumm und NFS-Clients sind intelligent. Es sind die Clients, die die Arbeit leisten, die erforderlich ist, um den generalisierten Dateizugriff, den Server bereitstellen, in eine Dateizugriffsmethode umzuwandeln, die für Anwendungen und Benutzer nützlich ist. Im oben gegebenen LINK-Beispiel würde ein UNIX-Client, der einen NFS3ERR_NOTSUP-Fehler von einem Server erhält, die notwendige Wiederherstellung durchführen, um es der Anwendung so erscheinen zu lassen, als ob die Link-Anfrage erfolgreich war, oder einen vernünftigen Fehler zurückgeben. Im Allgemeinen liegt die Verantwortung für die Wiederherstellung beim Client.

Das NFS Version 3 Protokoll geht von einer zustandslosen Serverimplementierung aus. Zustandslos bedeutet, dass der Server keinen Zustand über seine Clients aufrechterhalten muss, um korrekt zu funktionieren. Zustandslose Server haben im Falle eines Absturzes einen deutlichen Vorteil gegenüber zustandsbehafteten Servern. Bei zustandslosen Servern muss ein Client nur eine Anfrage wiederholen, bis der Server antwortet; der Client muss nicht einmal wissen, dass der Server abgestürzt ist. Siehe zusätzliche Kommentare in Duplicate Request Cache auf Seite 99.

Um nützlich zu sein, hält ein Server nicht-flüchtigen Zustand: Daten, die im Dateisystem gespeichert sind. Designannahmen im NFS Version 3 Protokoll bezüglich des Spülens geänderter Daten auf stabilen Speicher reduzieren die Anzahl der Fehlermodi, in denen Datenverlust auftreten kann. Auf diese Weise können NFS Version 3 Protokollimplementierungen vorübergehende Ausfälle tolerieren, einschließlich vorübergehender Ausfälle des Netzwerks. Im Allgemeinen können Serverimplementierungen des NFS Version 3 Protokolls einen nicht-vorübergehenden Ausfall des stabilen Speichers selbst nicht tolerieren. Es existieren jedoch fehlertolerante Implementierungen, die versuchen, solche Probleme anzugehen.

Das heißt nicht, dass ein NFS Version 3 Protokollserver keinen nicht-kritischen Zustand aufrechterhalten kann. In vielen Fällen werden Server Zustand (Cache) über frühere Operationen aufrechterhalten, um die Leistung zu erhöhen. Zum Beispiel könnte eine Client-READ-Anfrage ein Vorlesen des nächsten Blocks der Datei in den Daten-Cache des Servers auslösen, in Erwartung, dass der Client eine sequentielle Lesung durchführt und die nächste Client-READ-Anfrage aus dem Daten-Cache des Servers statt von der Festplatte erfüllt wird. Vorlesen auf dem Server erhöht die Leistung durch Überlappung von Server-Festplatten-I/O mit Client-Anfragen. Der wichtige Punkt hier ist, dass der vorgelesene Block nicht für korrektes Serververhalten erforderlich ist. Wenn der Server abstürzt und seinen Speicher-Cache von Lesepuffern verliert, ist die Wiederherstellung beim Neustart einfach - Clients werden Leseoperationen fortsetzen und Daten von der Server-Festplatte abrufen.

Die meisten datenmodifizierenden Operationen im NFS-Protokoll sind synchron. Das heißt, wenn eine datenmodifizierende Prozedur zum Client zurückkehrt, kann der Client annehmen, dass die Operation abgeschlossen ist und alle mit der Anfrage verbundenen geänderten Daten jetzt auf stabilem Speicher sind. Zum Beispiel kann eine synchrone Client-WRITE-Anfrage dazu führen, dass der Server Datenblöcke, Dateisysteminformationsblöcke und Dateiattributinformationen aktualisiert - letztere Informationen werden üblicherweise als Metadaten (metadata) bezeichnet. Wenn die WRITE-Operation abgeschlossen ist, kann der Client annehmen, dass die Schreibdaten sicher sind und sie verwerfen. Dies ist ein sehr wichtiger Teil der zustandslosen Natur des Servers. Wenn der Server dirty data nicht auf stabilen Speicher spülen würde, bevor er zum Client zurückkehrt, hätte der Client keine Möglichkeit zu wissen, wann es sicher ist, geänderte Daten zu verwerfen. Die folgenden datenmodifizierenden Prozeduren sind synchron: WRITE (mit stabilem Flag auf FILE_SYNC gesetzt), CREATE, MKDIR, SYMLINK, MKNOD, REMOVE, RMDIR, RENAME, LINK und COMMIT.

Das NFS Version 3 Protokoll führt sichere asynchrone Schreibvorgänge auf dem Server ein, wenn die WRITE-Prozedur in Verbindung mit der COMMIT-Prozedur verwendet wird. Die COMMIT-Prozedur bietet eine Möglichkeit für den Client, Daten von früheren asynchronen WRITE-Anfragen auf dem Server auf stabilen Speicher zu spülen und zu erkennen, ob es notwendig ist, die Daten erneut zu übertragen. Siehe die Prozedurbeschreibungen von WRITE auf Seite 49 und COMMIT auf Seite 92.

Die LOOKUP-Prozedur wird vom Client verwendet, um Mehrkomponenten-Dateinamen (Pfadnamen) zu durchlaufen. Jeder Aufruf von LOOKUP wird verwendet, um ein Segment eines Pfadnamens aufzulösen. Es gibt zwei Gründe, LOOKUP auf ein einzelnes Segment zu beschränken: Es ist schwierig, ein gemeinsames Format für hierarchische Dateinamen zu standardisieren, und Client und Server können unterschiedliche Mappings von Pfadnamen zu Dateisystemen haben. Dies würde implizieren, dass entweder der Client den Pfadnamen an Dateisystem-Anhängepunkten brechen muss oder der Server über die Dateisystem-Anhängepunkte des Clients Bescheid wissen muss. In NFS Version 3 Protokollimplementierungen ist es der Client, der den hierarchischen Dateinamenraum konstruiert, indem er Mounts verwendet, um eine Hierarchie aufzubauen. Unterstützungs-Utilities wie der Automounter bieten eine Möglichkeit, ein gemeinsames, konsistentes Bild des Dateinamenraums zu verwalten, während sie immer noch vom Client-Mount-Prozess gesteuert werden.

Clients können Caching auf verschiedene Weise durchführen. Die allgemeine Praxis beim NFS Version 2 Protokoll war die Implementierung eines zeitbasierten Client-Server-Cache-Konsistenzmechanismus. Es wird erwartet, dass NFS Version 3 Protokollimplementierungen einen ähnlichen Mechanismus verwenden werden. Das NFS Version 3 Protokoll hat einige explizite Unterstützung in Form zusätzlicher Attributinformationen, um explizite Attributprüfungen zu eliminieren. Caching ist jedoch nicht erforderlich, und es wird auch keine Caching-Richtlinie durch das Protokoll definiert. Weder das NFS Version 2 Protokoll noch das NFS Version 3 Protokoll bieten ein Mittel zur Aufrechterhaltung strikter Client-Server-Konsistenz (und implizit Konsistenz über Client-Caches hinweg).

1.7 Änderungen gegenüber dem NFS Version 2 Protokoll (Changes from the NFS Version 2 Protocol)

Die ROOT- und WRITECACHE-Prozeduren wurden entfernt. Eine MKNOD-Prozedur wurde definiert, um die Erstellung von Spezialdateien zu ermöglichen und die Überladung von CREATE zu eliminieren. Caching auf dem Client wird nicht durch das NFS Version 3 Protokoll definiert oder vorgeschrieben, aber zusätzliche Informationen und Hinweise wurden zum Protokoll hinzugefügt, um Clients, die Caching implementieren, zu ermöglichen, ihre Caches effektiver zu verwalten. Prozeduren, die die Attribute einer Datei oder eines Verzeichnisses beeinflussen, können nun die neuen Attribute nach Abschluss der Operation zurückgeben, um ein nachfolgendes GETATTR zu optimieren, das zur Validierung von Attribut-Caches verwendet wird. Darüber hinaus geben Operationen, die das Verzeichnis modifizieren, in dem sich das Zielobjekt befindet, die alten und neuen Attribute des Verzeichnisses zurück, um Clients zu ermöglichen, intelligentere Cache-Invalidierungsprozeduren zu implementieren. Die ACCESS-Prozedur bietet Zugriffsberechtigungsprüfung auf dem Server, die FSSTAT-Prozedur gibt dynamische Informationen über ein Dateisystem zurück, die FSINFO-Prozedur gibt statische Informationen über ein Dateisystem und einen Server zurück, die READDIRPLUS-Prozedur gibt Dateihandles und Attribute zusätzlich zu Verzeichniseinträgen zurück, und die PATHCONF-Prozedur gibt POSIX pathconf-Informationen über eine Datei zurück.

Im Folgenden finden Sie eine Liste der wichtigen Änderungen zwischen dem NFS Version 2 Protokoll und dem NFS Version 3 Protokoll.

Dateihandle-Größe (File handle size)

Das Dateihandle wurde von einem festen Array von 32 Bytes auf ein Array variabler Länge von maximal 64 Bytes erweitert. Dies adressiert einige bekannte Anforderungen für eine etwas größere Dateihandle-Größe. Das Dateihandle wurde von fester Länge auf variable Länge umgestellt, um die lokalen Speicher- und Netzwerkbandbreitenanforderungen für Systeme zu reduzieren, die nicht die vollen 64 Bytes Länge nutzen.

Maximale Datengrößen (Maximum data sizes)

Die maximale Größe einer Datenübertragung, die in den READ- und WRITE-Prozeduren verwendet wird, wird nun durch Werte in der FSINFO-Rückgabestruktur festgelegt. Zusätzlich werden bevorzugte Übertragungsgrößen von FSINFO zurückgegeben. Das Protokoll legt keine künstlichen Grenzen für die maximalen Übertragungsgrößen fest.

Dateinamen und Pfadnamen werden nun als Zeichenfolgen variabler Länge spezifiziert. Die tatsächlichen Längenbeschränkungen werden von den Client- und Serverimplementierungen angemessen bestimmt. Das Protokoll legt keine künstlichen Grenzen für die Länge fest. Der Fehler NFS3ERR_NAMETOOLONG wird bereitgestellt, um dem Server zu ermöglichen, dem Client eine Anzeige zurückzugeben, dass er einen Pfadnamen erhalten hat, der zu lang für ihn zum Verarbeiten ist.

Fehlerrückgabe (Error return)

Fehlerrückgaben geben in einigen Fällen nun Daten zurück (z.B. Attribute). nfsstat3 definiert nun den vollständigen Satz von Fehlern, die von einem Server zurückgegeben werden können. Keine anderen Werte sind erlaubt.

Dateityp (File type)

Der Dateityp umfasst nun NF3CHR und NF3BLK für Spezialdateien. Attribute für diese Typen enthalten Unterfelder für UNIX-Haupt- und Nebengerätenummern. NF3SOCK und NF3FIFO sind nun für Sockets und FIFOs im Dateisystem definiert.

Dateiattribute (File attributes)

Das blocksize-Feld (die Größe in Bytes eines Blocks in der Datei) wurde entfernt. Das mode-Feld enthält keine Dateitypinformationen mehr. Die Felder size und fileid wurden von Vier-Byte-Ganzzahlen auf Acht-Byte-Ganzzahlen ohne Vorzeichen erweitert. Haupt- und Nebengerätenummerinformationen werden nun in einer eigenen Struktur präsentiert. Der Feldname blocks wurde in used geändert und enthält nun die Gesamtanzahl der von der Datei verwendeten Bytes. Es ist auch eine Acht-Byte-Ganzzahl ohne Vorzeichen.

Dateiattribute setzen (Set file attributes)

Im NFS Version 2 Protokoll wurden die setzbaren Attribute durch eine Teilmenge der Dateiattributstruktur dargestellt; der Client gab an, welche Attribute nicht geändert werden sollten, indem er das entsprechende Feld auf -1 setzte, wodurch einige Felder ohne Vorzeichen überladen wurden. Die Struktur zum Setzen von Dateiattributen verwendet nun eine diskriminierte Union für jedes Feld, um zu sagen, ob oder wie dieses Feld gesetzt werden soll. Die Felder atime und mtime können entweder auf die aktuelle Zeit des Servers oder auf eine vom Client bereitgestellte Zeit gesetzt werden.

LOOKUP

Die LOOKUP-Rückgabestruktur enthält nun die Attribute für das durchsuchte Verzeichnis.

ACCESS

Eine ACCESS-Prozedur wurde hinzugefügt, um eine explizite Over-the-Wire-Berechtigungsprüfung zu ermöglichen. Dies adressiert bekannte Probleme mit der Superuser-ID-Mapping-Funktion in vielen Serverimplementierungen (wo aufgrund des Mappings des Root-Benutzers unerwartete "Berechtigung verweigert"-Fehler beim Lesen oder Schreiben in eine Datei auftreten konnten). Dies entfernt auch die Annahme, die im NFS Version 2 Protokoll gemacht wurde, dass der Zugriff auf Dateien ausschließlich auf UNIX-Style-Modus-Bits basierte.

READ

Die Antwortstruktur enthält einen Boolean, der TRUE ist, wenn das Dateiende während des READ erreicht wurde. Dies ermöglicht es dem Client, das Dateiende korrekt zu erkennen.

WRITE

Die Felder beginoffset und totalcount wurden aus den WRITE-Argumenten entfernt. Die Antwort enthält nun einen Zähler, damit der Server weniger als die angeforderte Datenmenge schreiben kann, falls erforderlich. Ein Indikator wurde den Argumenten hinzugefügt, um dem Server die vom Client benötigte Cache-Synchronisierungsebene anzuzeigen.

CREATE

Ein Exclusiv-Flag und ein Create-Verifizierer wurden für die exklusive Erstellung regulärer Dateien hinzugefügt.

MKNOD

Diese Prozedur wurde hinzugefügt, um die Erstellung von Spezialdateien zu unterstützen. Dies vermeidet das Überladen von Feldern von CREATE, wie es in einigen NFS Version 2 Protokollimplementierungen getan wurde.

READDIR

Die READDIR-Argumente enthalten nun einen Verifizierer, um dem Server zu ermöglichen, das Cookie zu validieren. Das Cookie ist nun eine 64-Bit-Ganzzahl ohne Vorzeichen anstelle des 4-Byte-Arrays, das im NFS Version 2 Protokoll verwendet wurde. Dies wird helfen, Interoperabilitätsprobleme zu reduzieren.

READDIRPLUS

Diese Prozedur wurde hinzugefügt, um Dateihandles und Attribute in einer erweiterten Verzeichnisliste zurückzugeben.

FSINFO

FSINFO wurde hinzugefügt, um nicht-flüchtige Informationen über ein Dateisystem bereitzustellen. Die Antwort enthält bevorzugte und maximale Lese-Übertragungsgröße, bevorzugte und maximale Schreib-Übertragungsgröße und Flags, die angeben, ob Links oder symbolische Links unterstützt werden. Ebenfalls zurückgegeben werden die bevorzugte Übertragungsgröße für READDIR-Prozedur-Antworten, die Server-Zeitgranularität und ob Zeiten in einer SETATTR-Anfrage gesetzt werden können.

FSSTAT

FSSTAT wurde hinzugefügt, um flüchtige Informationen über ein Dateisystem bereitzustellen, zur Verwendung durch Utilities wie den Unix-Systembefehl df. Die Antwort enthält die Gesamtgröße und den freien Speicherplatz im Dateisystem, angegeben in Bytes, die Gesamtanzahl der Dateien und die Anzahl der freien Dateislots im Dateisystem sowie eine Schätzung der Zeit zwischen Dateisystemänderungen (zur Verwendung in Cache-Konsistenzprüfungsalgorithmen).

COMMIT

Die COMMIT-Prozedur bietet den Synchronisierungsmechanismus zur Verwendung mit asynchronen WRITE-Operationen.

---