RFC 1813 - NFS Version 3 Protokollspezifikation (NFS Version 3 Protocol Specification)
- Status: Informational
- Veröffentlicht: June 1995
- Stream: Legacy
- Errata: Keine Errata
Zusammenfassung (Abstract)
Dieses Dokument beschreibt das NFS Version 3 Protokoll. Dieses Dokument wird bereitgestellt, damit Personen kompatible Implementierungen schreiben können.
Inhaltsverzeichnis (Table of Contents)
- 1. Introduction (Einführung)
- 1.1 Scope of the NFS version 3 protocol (Umfang des NFS Version 3 Protokolls)
- 1.2 Useful terms (Nützliche Begriffe)
- 1.3 Remote Procedure Call (Remote-Prozeduraufruf)
- 1.4 External Data Representation (Externe Datendarstellung)
- 1.5 Authentication and Permission Checking (Authentifizierung und Berechtigungsprüfung)
- 1.6 Philosophy (Philosophie)
- 1.7 Changes from the NFS version 2 protocol (Änderungen gegenüber dem NFS Version 2 Protokoll)
- 2. RPC Information (RPC-Informationen)
- 2.1 Authentication (Authentifizierung)
- 2.2 Constants (Konstanten)
- 2.3 Transport address (Transportadresse)
- 2.4 Sizes (Größen)
- 2.5 Basic Data Types (Grundlegende Datentypen)
- 2.6 Defined Error Numbers (Definierte Fehlernummern)
- 3. Server Procedures (Server-Prozeduren)
- 3.1 General comments on attributes (Allgemeine Bemerkungen zu Attributen)
- 3.2 General comments on filenames (Allgemeine Bemerkungen zu Dateinamen)
- 3.3.0 NULL: Do nothing (Nichts tun)
- 3.3.1 GETATTR: Get file attributes (Dateiattribute abrufen)
- 3.3.2 SETATTR: Set file attributes (Dateiattribute setzen)
- 3.3.3 LOOKUP: Lookup filename (Dateinamen suchen)
- 3.3.4 ACCESS: Check access permission (Zugriffsberechtigung prüfen)
- 3.3.5 READLINK: Read from symbolic link (Von symbolischem Link lesen)
- 3.3.6 READ: Read from file (Von Datei lesen)
- 3.3.7 WRITE: Write to file (In Datei schreiben)
- 3.3.8 CREATE: Create a file (Datei erstellen)
- 3.3.9 MKDIR: Create a directory (Verzeichnis erstellen)
- 3.3.10 SYMLINK: Create a symbolic link (Symbolischen Link erstellen)
- 3.3.11 MKNOD: Create a special device (Spezielles Gerät erstellen)
- 3.3.12 REMOVE: Remove a file (Datei entfernen)
- 3.3.13 RMDIR: Remove a directory (Verzeichnis entfernen)
- 3.3.14 RENAME: Rename a file or directory (Datei oder Verzeichnis umbenennen)
- 3.3.15 LINK: Create link to an object (Link zu einem Objekt erstellen)
- 3.3.16 READDIR: Read From directory (Aus Verzeichnis lesen)
- 3.3.17 READDIRPLUS: Extended read from directory (Erweitertes Lesen aus Verzeichnis)
- 3.3.18 FSSTAT: Get dynamic file system information (Dynamische Dateisysteminformationen abrufen)
- 3.3.19 FSINFO: Get static file system information (Statische Dateisysteminformationen abrufen)
- 3.3.20 PATHCONF: Retrieve POSIX information (POSIX-Informationen abrufen)
- 3.3.21 COMMIT: Commit cached data on a server to stable storage (Zwischengespeicherte Daten auf einem Server in stabilen Speicher übertragen)
- 4. Implementation issues (Implementierungsfragen)
- 4.1 Multiple version support (Unterstützung mehrerer Versionen)
- 4.2 Server/client relationship (Server-/Client-Beziehung)
- 4.3 Path name interpretation (Pfadnameninterpretation)
- 4.4 Permission issues (Berechtigungsfragen)
- 4.5 Duplicate request cache (Cache für doppelte Anfragen)
- 4.6 File name component handling (Behandlung von Dateinamenkomponenten)
- 4.7 Synchronous modifying operations (Synchrone Änderungsoperationen)
- 4.8 Stable storage (Stabiler Speicher)
- 4.9 Lookups and name resolution (Suchen und Namensauflösung)
- 4.10 Adaptive retransmission (Adaptive Neuübertragung)
- 4.11 Caching policies (Caching-Richtlinien)
- 4.12 Stable versus unstable writes (Stabile versus instabile Schreibvorgänge)
- 4.13 32 bit clients/servers and 64 bit clients/servers (32-Bit-Clients/Server und 64-Bit-Clients/Server)
- 5. Appendix I: Mount protocol (Anhang I: Mount-Protokoll)
- 5.1 RPC Information (RPC-Informationen)
- 5.2 Server Procedures (Server-Prozeduren)
- 6. Appendix II: Lock manager protocol (Anhang II: Lock-Manager-Protokoll)
- 6.1 RPC Information (RPC-Informationen)
- 6.2 NLM Procedures (NLM-Prozeduren)
- 6.3 Implementation issues (Implementierungsfragen)
- 7. Appendix III: Bibliography (Anhang III: Bibliographie)
- 8. Security Considerations (Sicherheitsüberlegungen)
- 9. Acknowledgements (Danksagungen)
- 10. Authors' Addresses (Adressen der Autoren)
Verwandte Ressourcen (Related Resources)
- Offizielles RFC: RFC 1813
- DataTracker: RFC 1813 on IETF
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:
-
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.
-
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.
-
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.
2. RPC-Informationen (RPC Information)
2.1 Authentifizierung (Authentication)
Der NFS-Dienst verwendet AUTH_NONE in der NULL-Prozedur. AUTH_UNIX, AUTH_DES oder AUTH_KERB werden für alle anderen Prozeduren verwendet. Andere Authentifizierungstypen können in Zukunft unterstützt werden.
2.2 Konstanten (Constants)
Dies sind die RPC-Konstanten, die zum Aufruf des NFS Version 3 Dienstes benötigt werden. Sie werden in Dezimalform angegeben.
PROGRAM 100003
VERSION 3
2.3 Transportadresse (Transport address)
Das NFS-Protokoll wird normalerweise über die TCP- und UDP-Protokolle unterstützt. Es verwendet Port 2049, denselben wie das NFS Version 2 Protokoll.
2.4 Größen (Sizes)
Dies sind die Größen in dezimalen Bytes verschiedener XDR-Strukturen, die im NFS Version 3 Protokoll verwendet werden:
NFS3_FHSIZE 64
- Die maximale Größe in Bytes des opaken Datei-Handles.
NFS3_COOKIEVERFSIZE 8
- Die Größe in Bytes des opaken Cookie-Verifizierers, der von READDIR und READDIRPLUS übergeben wird.
NFS3_CREATEVERFSIZE 8
- Die Größe in Bytes des opaken Verifizierers, der für exklusives CREATE verwendet wird.
NFS3_WRITEVERFSIZE 8
- Die Größe in Bytes des opaken Verifizierers, der für asynchrones WRITE verwendet wird.
2.5 Grundlegende Datentypen (Basic Data Types)
Die folgenden XDR-Definitionen sind grundlegende Definitionen, die in anderen Strukturen verwendet werden.
uint64
typedef unsigned hyper uint64;
int64
typedef hyper int64;
uint32
typedef unsigned long uint32;
int32
typedef long int32;
filename3
typedef string filename3<>;
nfspath3
typedef string nfspath3<>;
fileid3
typedef uint64 fileid3;
cookie3
typedef uint64 cookie3;
cookieverf3
typedef opaque cookieverf3[NFS3_COOKIEVERFSIZE];
createverf3
typedef opaque createverf3[NFS3_CREATEVERFSIZE];
writeverf3
typedef opaque writeverf3[NFS3_WRITEVERFSIZE];
uid3
typedef uint32 uid3;
gid3
typedef uint32 gid3;
size3
typedef uint64 size3;
offset3
typedef uint64 offset3;
mode3
typedef uint32 mode3;
count3
typedef uint32 count3;
nfsstat3
enum nfsstat3 {
NFS3_OK = 0,
NFS3ERR_PERM = 1,
NFS3ERR_NOENT = 2,
NFS3ERR_IO = 5,
NFS3ERR_NXIO = 6,
NFS3ERR_ACCES = 13,
NFS3ERR_EXIST = 17,
NFS3ERR_XDEV = 18,
NFS3ERR_NODEV = 19,
NFS3ERR_NOTDIR = 20,
NFS3ERR_ISDIR = 21,
NFS3ERR_INVAL = 22,
NFS3ERR_FBIG = 27,
NFS3ERR_NOSPC = 28,
NFS3ERR_ROFS = 30,
NFS3ERR_MLINK = 31,
NFS3ERR_NAMETOOLONG = 63,
NFS3ERR_NOTEMPTY = 66,
NFS3ERR_DQUOT = 69,
NFS3ERR_STALE = 70,
NFS3ERR_REMOTE = 71,
NFS3ERR_BADHANDLE = 10001,
NFS3ERR_NOT_SYNC = 10002,
NFS3ERR_BAD_COOKIE = 10003,
NFS3ERR_NOTSUPP = 10004,
NFS3ERR_TOOSMALL = 10005,
NFS3ERR_SERVERFAULT = 10006,
NFS3ERR_BADTYPE = 10007,
NFS3ERR_JUKEBOX = 10008
};
Der Typ nfsstat3 wird mit den Ergebnissen jeder Prozedur zurückgegeben, außer bei der NULL-Prozedur. Ein Wert von NFS3_OK zeigt an, dass der Aufruf erfolgreich abgeschlossen wurde. Jeder andere Wert zeigt an, dass beim Aufruf ein Fehler aufgetreten ist, der durch den Fehlercode identifiziert wird. Beachten Sie, dass die präzise numerische Kodierung befolgt werden muss. Keine anderen Werte dürfen von einem Server zurückgegeben werden. Server werden erwartet, eine bestmögliche Zuordnung von Fehlerbedingungen zu der definierten Menge von Fehlercodes vorzunehmen. Darüber hinaus werden in dieser Spezifikation keine Fehlerpriorisierungen angegeben. Fehlerpriorisierungen bestimmen den Fehlerwert, der zurückgegeben werden soll, wenn mehr als ein Fehler in einer gegebenen Situation zutrifft. Die Fehlerpriorisierung wird durch die individuelle Server-Implementierung bestimmt. Wenn der Client spezifische Fehlerpriorisierungen benötigt, sollte er selbst nach den spezifischen Fehlern suchen.
2.6 Definierte Fehlernummern (Defined Error Numbers)
Eine Beschreibung jedes definierten Fehlers folgt:
NFS3_OK
- Zeigt an, dass der Aufruf erfolgreich abgeschlossen wurde.
NFS3ERR_PERM
- Nicht Eigentümer. Die Operation wurde nicht erlaubt, weil der Aufrufer entweder kein privilegierter Benutzer (root) ist oder nicht der Eigentümer des Ziels der Operation ist.
NFS3ERR_NOENT
- Datei oder Verzeichnis nicht vorhanden. Der angegebene Datei- oder Verzeichnisname existiert nicht.
NFS3ERR_IO
- I/O-Fehler. Ein harter Fehler (zum Beispiel ein Festplattenfehler) ist während der Verarbeitung der angeforderten Operation aufgetreten.
NFS3ERR_NXIO
- I/O-Fehler. Kein solches Gerät oder Adresse.
NFS3ERR_ACCES
- Zugriff verweigert. Der Aufrufer hat nicht die korrekte Berechtigung, um die angeforderte Operation auszuführen. Vergleichen Sie dies mit NFS3ERR_PERM, das sich auf Eigentümer- oder privilegierte Benutzerberechtigungsfehler beschränkt.
NFS3ERR_EXIST
- Datei existiert. Die angegebene Datei existiert bereits.
NFS3ERR_XDEV
- Versuch, einen geräteübergreifenden harten Link zu erstellen.
NFS3ERR_NODEV
- Kein solches Gerät.
NFS3ERR_NOTDIR
- Kein Verzeichnis. Der Aufrufer hat ein Nicht-Verzeichnis in einer Verzeichnisoperation angegeben.
NFS3ERR_ISDIR
- Ist ein Verzeichnis. Der Aufrufer hat ein Verzeichnis in einer Nicht-Verzeichnisoperation angegeben.
NFS3ERR_INVAL
- Ungültiges Argument oder nicht unterstütztes Argument für eine Operation. Zwei Beispiele sind der Versuch eines READLINK auf einem anderen Objekt als einem symbolischen Link oder der Versuch eines SETATTR eines Zeitfeldes auf einem Server, der diese Operation nicht unterstützt.
NFS3ERR_FBIG
- Datei zu groß. Die Operation hätte dazu geführt, dass eine Datei über die Grenze des Servers hinaus wächst.
NFS3ERR_NOSPC
- Kein Speicherplatz mehr auf dem Gerät. Die Operation hätte dazu geführt, dass das Dateisystem des Servers seine Grenze überschreitet.
NFS3ERR_ROFS
- Nur-Lese-Dateisystem. Eine modifizierende Operation wurde auf einem Nur-Lese-Dateisystem versucht.
NFS3ERR_MLINK
- Zu viele harte Links.
NFS3ERR_NAMETOOLONG
- Der Dateiname in einer Operation war zu lang.
NFS3ERR_NOTEMPTY
- Es wurde versucht, ein nicht leeres Verzeichnis zu entfernen.
NFS3ERR_DQUOT
- Ressourcen (Quota) Hardlimit überschritten. Das Ressourcenlimit des Benutzers auf dem Server wurde überschritten.
NFS3ERR_STALE
- Ungültiges Datei-Handle. Das in den Argumenten angegebene Datei-Handle war ungültig. Die durch dieses Datei-Handle referenzierte Datei existiert nicht mehr oder der Zugriff darauf wurde widerrufen.
NFS3ERR_REMOTE
- Zu viele Ebenen von Remote im Pfad. Das in den Argumenten angegebene Datei-Handle bezog sich auf eine Datei auf einem nicht-lokalen Dateisystem auf dem Server.
NFS3ERR_BADHANDLE
- Illegales NFS-Datei-Handle. Das Datei-Handle hat interne Konsistenzprüfungen nicht bestanden.
NFS3ERR_NOT_SYNC
- Update-Synchronisationskonflikt wurde während einer SETATTR-Operation erkannt.
NFS3ERR_BAD_COOKIE
- READDIR- oder READDIRPLUS-Cookie ist veraltet.
NFS3ERR_NOTSUPP
- Operation wird nicht unterstützt.
NFS3ERR_TOOSMALL
- Puffer oder Anfrage ist zu klein.
NFS3ERR_SERVERFAULT
- Ein Fehler ist auf dem Server aufgetreten, der auf keinen der legalen NFS Version 3 Protokollfehlerwerte abbildet. Der Client sollte dies in einen geeigneten Fehler übersetzen. UNIX-Clients können wählen, dies in EIO zu übersetzen.
NFS3ERR_BADTYPE
- Es wurde versucht, ein Objekt eines vom Server nicht unterstützten Typs zu erstellen.
NFS3ERR_JUKEBOX
- Der Server hat die Anfrage initiiert, konnte sie jedoch nicht rechtzeitig abschließen. Der Client sollte warten und dann die Anfrage mit einer neuen RPC-Transaktions-ID wiederholen. Zum Beispiel sollte dieser Fehler von einem Server zurückgegeben werden, der hierarchischen Speicher unterstützt und eine Anfrage zur Verarbeitung einer migrierten Datei erhält. In diesem Fall sollte der Server den Immigrationsprozess starten und dem Client mit diesem Fehler antworten.
ftype3
enum ftype3 {
NF3REG = 1,
NF3DIR = 2,
NF3BLK = 3,
NF3CHR = 4,
NF3LNK = 5,
NF3SOCK = 6,
NF3FIFO = 7
};
Die Aufzählung ftype3 gibt den Typ einer Datei an. Der Typ NF3REG ist eine reguläre Datei, NF3DIR ist ein Verzeichnis, NF3BLK ist eine spezielle Block-Gerätedatei, NF3CHR ist eine spezielle Zeichen-Gerätedatei, NF3LNK ist ein symbolischer Link, NF3SOCK ist ein Socket und NF3FIFO ist eine benannte Pipe. Beachten Sie, dass die präzise Enum-Kodierung befolgt werden muss.
specdata3
struct specdata3 {
uint32 specdata1;
uint32 specdata2;
};
Die Interpretation der beiden Wörter hängt vom Typ des Dateisystemobjekts ab. Für eine spezielle Block- (NF3BLK) oder Zeichen-Datei (NF3CHR) sind specdata1 und specdata2 jeweils die Major- und Minor-Gerätenummern. (Dies ist offensichtlich eine UNIX-spezifische Interpretation.) Für alle anderen Dateitypen sollten diese beiden Elemente entweder auf 0 gesetzt werden oder die Werte sollten zwischen Client und Server vereinbart werden. Wenn Client und Server sich nicht über die Werte einig sind, sollte der Client diese Felder so behandeln, als ob sie auf 0 gesetzt wären. Dieses Datenfeld wird als Teil der fattr3-Struktur zurückgegeben und ist daher aus allen Antworten verfügbar, die Attribute zurückgeben. Da diese Felder für Objekte, die keine Geräte sind, anderweitig ungenutzt sind, können Out-of-Band-Informationen vom Server an den Client weitergegeben werden. Jedoch müssen sich sowohl Server als auch Client über die übergebenen Werte einig sein.
nfs_fh3
struct nfs_fh3 {
opaque data<NFS3_FHSIZE>;
};
Das nfs_fh3 ist das opake Objekt mit variabler Länge, das vom Server bei LOOKUP-, CREATE-, SYMLINK-, MKNOD-, LINK- oder READDIRPLUS-Operationen zurückgegeben wird und vom Client bei nachfolgenden Operationen verwendet wird, um auf die Datei zu verweisen. Das Datei-Handle enthält alle Informationen, die der Server benötigt, um eine einzelne Datei zu unterscheiden. Für den Client ist das Datei-Handle opak. Der Client speichert Datei-Handles zur Verwendung in einer späteren Anfrage und kann zwei Datei-Handles vom selben Server auf Gleichheit vergleichen, indem er einen Byte-für-Byte-Vergleich durchführt, kann aber den Inhalt der Datei-Handles nicht anderweitig interpretieren. Wenn zwei Datei-Handles vom selben Server gleich sind, müssen sie sich auf dieselbe Datei beziehen, aber wenn sie nicht gleich sind, können keine Schlüsse gezogen werden. Server sollten versuchen, eine Eins-zu-eins-Korrespondenz zwischen Datei-Handles und Dateien aufrechtzuerhalten, aber dies ist nicht erforderlich. Clients sollten Datei-Handle-Vergleiche nur zur Verbesserung der Leistung verwenden, nicht für korrektes Verhalten.
Server können den durch ein Datei-Handle bereitgestellten Zugriff jederzeit widerrufen. Wenn das in einem Aufruf übergebene Datei-Handle sich auf ein Dateisystemobjekt bezieht, das auf dem Server nicht mehr existiert, oder wenn der Zugriff für dieses Datei-Handle widerrufen wurde, sollte der Fehler NFS3ERR_STALE zurückgegeben werden.
nfstime3
struct nfstime3 {
uint32 seconds;
uint32 nseconds;
};
Die nfstime3-Struktur gibt die Anzahl der Sekunden und Nanosekunden seit Mitternacht, 1. Januar 1970 Greenwich Mean Time an. Sie wird verwendet, um Zeit- und Datumsinformationen zu übergeben. Die mit Dateien verbundenen Zeiten sind alle Serverzeiten, außer im Fall einer SETATTR-Operation, bei der der Client die Dateizeit explizit setzen kann. Ein Server konvertiert bei der Verarbeitung von Zeitwerten zur und von der Ortszeit und bewahrt dabei so viel Genauigkeit wie möglich. Wenn die Präzision der für eine Datei gespeicherten Zeitstempel geringer ist als die vom NFS Version 3 Protokoll definierte, kann ein Präzisionsverlust auftreten. Ein ergänzendes Zeitwartungsprotokoll wird empfohlen, um die Zeit-Diskrepanz zwischen Client und Server zu reduzieren.
fattr3
struct fattr3 {
ftype3 type;
mode3 mode;
uint32 nlink;
uid3 uid;
gid3 gid;
size3 size;
size3 used;
specdata3 rdev;
uint64 fsid;
fileid3 fileid;
nfstime3 atime;
nfstime3 mtime;
nfstime3 ctime;
};
Diese Struktur definiert die Attribute eines Dateisystemobjekts. Sie wird von den meisten Operationen auf einem Objekt zurückgegeben; im Fall von Operationen, die zwei Objekte betreffen (zum Beispiel ein MKDIR, das die Zielverzeichnisattribute modifiziert und neue Attribute für das neu erstellte Verzeichnis definiert), können die Attribute für beide zurückgegeben werden. In einigen Fällen werden die Attribute in der unten definierten Struktur wcc_data zurückgegeben; in anderen Fällen werden die Attribute allein zurückgegeben. Die Hauptänderungen gegenüber dem NFS Version 2 Protokoll sind, dass viele der Felder erweitert wurden und die Major/Minor-Geräteinformationen jetzt in einer separaten Struktur dargestellt werden, anstatt in ein Wort gepackt zu werden.
Die fattr3-Struktur enthält die grundlegenden Attribute einer Datei. Alle Server sollten diese Menge von Attributen unterstützen, auch wenn sie einige der Felder simulieren müssen. Type ist der Typ der Datei. Mode sind die Schutzmodusbits. Nlink ist die Anzahl der harten Links zur Datei - das heißt, die Anzahl verschiedener Namen für dieselbe Datei. Uid ist die Benutzer-ID des Eigentümers der Datei. Gid ist die Gruppen-ID der Gruppe der Datei. Size ist die Größe der Datei in Bytes. Used ist die Anzahl der Bytes Festplattenspeicher, die die Datei tatsächlich verwendet (was kleiner als die Größe sein kann, weil die Datei Löcher haben kann, oder größer aufgrund von Fragmentierung). Rdev beschreibt die Gerätedatei, wenn der Dateityp NF3CHR oder NF3BLK ist - siehe specdata3 auf Seite 20. Fsid ist der Dateisystemidentifikator für das Dateisystem. Fileid ist eine Nummer, die die Datei innerhalb ihres Dateisystems eindeutig identifiziert (auf UNIX wäre dies die Inumber). Atime ist die Zeit, zu der die Dateidaten zuletzt zugegriffen wurden. Mtime ist die Zeit, zu der die Dateidaten zuletzt modifiziert wurden. Ctime ist die Zeit, zu der die Attribute der Datei zuletzt geändert wurden. Das Schreiben in die Datei ändert zusätzlich zur mtime auch die ctime.
Die Modusbits sind wie folgt definiert:
0x00800 Setze Benutzer-ID bei Ausführung.
0x00400 Setze Gruppen-ID bei Ausführung.
0x00200 Speichere getauschten Text (nicht in POSIX definiert).
0x00100 Leseberechtigung für Eigentümer.
0x00080 Schreibberechtigung für Eigentümer.
0x00040 Ausführungsberechtigung für Eigentümer auf einer Datei. Oder Such-(Lookup-)Berechtigung für Eigentümer im Verzeichnis.
0x00020 Leseberechtigung für Gruppe.
0x00010 Schreibberechtigung für Gruppe.
0x00008 Ausführungsberechtigung für Gruppe auf einer Datei. Oder Such-(Lookup-)Berechtigung für Gruppe im Verzeichnis.
0x00004 Leseberechtigung für andere.
0x00002 Schreibberechtigung für andere.
0x00001 Ausführungsberechtigung für andere auf einer Datei. Oder Such-(Lookup-)Berechtigung für andere im Verzeichnis.
post_op_attr
union post_op_attr switch (bool attributes_follow) {
case TRUE:
fattr3 attributes;
case FALSE:
void;
};
Diese Struktur wird verwendet, um Attribute in Operationen zurückzugeben, die nicht direkt an der Manipulation von Attributen beteiligt sind. Eines der Prinzipien dieser Revision des NFS-Protokolls ist es, den tatsächlichen Wert aus der angegebenen Operation zurückzugeben und nicht einen Fehler aus einer nebensächlichen Operation. Die post_op_attr-Struktur wurde entwickelt, um dem Server zu ermöglichen, sich von Fehlern zu erholen, die beim Abrufen von Attributen auftreten.
Dies scheint die Rückgabe von Attributen optional zu machen. Server-Implementierer werden jedoch nachdrücklich ermutigt, sich nach Kräften zu bemühen, Attribute wann immer möglich zurückzugeben, auch wenn ein Fehler zurückgegeben wird.
wcc_attr
struct wcc_attr {
size3 size;
nfstime3 mtime;
nfstime3 ctime;
};
Dies ist die Teilmenge der Präoperationsattribute, die benötigt wird, um die Semantik der schwachen Cache-Konsistenz besser zu unterstützen. Size ist die Dateigröße in Bytes des Objekts vor der Operation. Mtime ist die Zeit der letzten Modifikation des Objekts vor der Operation. Ctime ist die Zeit der letzten Änderung der Attribute des Objekts vor der Operation. Siehe Diskussion in wcc_attr auf Seite 24.
Die Verwendung von mtime durch Clients zur Erkennung von Änderungen an Dateisystemobjekten, die sich auf einem Server befinden, ist abhängig von der Granularität der Zeitbasis auf dem Server.
pre_op_attr
union pre_op_attr switch (bool attributes_follow) {
case TRUE:
wcc_attr attributes;
case FALSE:
void;
};
wcc_data
struct wcc_data {
pre_op_attr before;
post_op_attr after;
};
Wenn ein Client eine Operation durchführt, die den Zustand einer Datei oder eines Verzeichnisses auf dem Server modifiziert, kann er aus den Postoperationsattributen nicht sofort bestimmen, ob die gerade durchgeführte Operation die einzige Operation am Objekt seit dem letzten Empfang der Attribute für das Objekt durch den Client war. Dies ist wichtig, denn wenn eine zwischenzeitliche Operation das Objekt geändert hat, muss der Client alle zwischengespeicherten Daten für das Objekt ungültig machen (außer den Daten, die er gerade geschrieben hat).
Um damit umzugehen, wird das Konzept der schwachen Cache-Konsistenzdaten oder wcc_data eingeführt. Eine wcc_data-Struktur besteht aus bestimmten Schlüsselfeldern aus den Objektattributen vor der Operation zusammen mit den Objektattributen nach der Operation. Diese Informationen ermöglichen es dem Client, seinen Cache genauer zu verwalten als in NFS Version 2 Protokollimplementierungen. Der Begriff schwache Cache-Konsistenz betont die Tatsache, dass dieser Mechanismus nicht die strenge Server-Client-Konsistenz bietet, die ein Cache-Konsistenzprotokoll bieten würde.
Um das Modell der schwachen Cache-Konsistenz zu unterstützen, muss der Server in der Lage sein, die Präoperationsattribute des Objekts zu erhalten, die beabsichtigte Modifikationsoperation durchzuführen und dann atomar die Postoperationsattribute zu erhalten. Wenn es ein Fenster gibt, in dem das Objekt zwischen der Operation und einer der Get-Attributes-Operationen modifiziert werden kann, dann kann der Client nicht bestimmen, ob er die einzige Entität war, die das Objekt modifiziert hat. Einige Informationen sind verloren gegangen, wodurch die Garantien der schwachen Cache-Konsistenz geschwächt werden.
post_op_fh3
union post_op_fh3 switch (bool handle_follows) {
case TRUE:
nfs_fh3 handle;
case FALSE:
void;
};
Eines der Prinzipien dieser Revision des NFS-Protokolls ist es, den tatsächlichen Wert aus der angegebenen Operation zurückzugeben und nicht einen Fehler aus einer nebensächlichen Operation. Die post_op_fh3-Struktur wurde entwickelt, um dem Server zu ermöglichen, sich von Fehlern zu erholen, die beim Konstruieren eines Datei-Handles auftreten.
Dies ist die Struktur, die verwendet wird, um ein Datei-Handle aus den Anfragen CREATE, MKDIR, SYMLINK, MKNOD und READDIRPLUS zurückzugeben. In jedem Fall kann der Client das Datei-Handle erhalten, indem er nach einer erfolgreichen Rückkehr von einer der aufgelisteten Operationen eine LOOKUP-Anfrage ausgibt. Die Rückgabe des Datei-Handles ist eine Optimierung, sodass der Client nicht gezwungen ist, sofort eine LOOKUP-Anfrage auszugeben, um das Datei-Handle zu erhalten.
sattr3
enum time_how {
DONT_CHANGE = 0,
SET_TO_SERVER_TIME = 1,
SET_TO_CLIENT_TIME = 2
};
union set_mode3 switch (bool set_it) {
case TRUE:
mode3 mode;
default:
void;
};
union set_uid3 switch (bool set_it) {
case TRUE:
uid3 uid;
default:
void;
};
union set_gid3 switch (bool set_it) {
case TRUE:
gid3 gid;
default:
void;
};
union set_size3 switch (bool set_it) {
case TRUE:
size3 size;
default:
void;
};
union set_atime switch (time_how set_it) {
case SET_TO_CLIENT_TIME:
nfstime3 atime;
default:
void;
};
union set_mtime switch (time_how set_it) {
case SET_TO_CLIENT_TIME:
nfstime3 mtime;
default:
void;
};
struct sattr3 {
set_mode3 mode;
set_uid3 uid;
set_gid3 gid;
set_size3 size;
set_atime atime;
set_mtime mtime;
};
Die sattr3-Struktur enthält die Dateiattribute, die vom Client gesetzt werden können. Die Felder sind dieselben wie die ähnlich benannten Felder in der fattr3-Struktur. Im NFS Version 3 Protokoll werden die setzbaren Attribute durch eine Struktur beschrieben, die eine Menge diskriminierter Unions enthält. Jede Union gibt an, ob das entsprechende Attribut aktualisiert werden soll und wenn ja, wie.
Es werden zwei Formen diskriminierter Unions verwendet. Beim Setzen von mode, uid, gid oder size wird die diskriminierte Union über einen Boolean, set_it, geschaltet; wenn dieser TRUE ist, wird dann ein Wert des entsprechenden Typs kodiert.
Beim Setzen von atime oder mtime wird die Union über einen Aufzählungstyp, set_it, geschaltet. Wenn set_it den Wert DONT_CHANGE hat, bleibt das entsprechende Attribut unverändert. Wenn es den Wert SET_TO_SERVER_TIME hat, wird das entsprechende Attribut vom Server auf seine Ortszeit gesetzt; vom Client werden keine Daten bereitgestellt. Schließlich, wenn set_it den Wert SET_TO_CLIENT_TIME hat, wird das Attribut auf die Zeit gesetzt, die der Client in einer nfstime3-Struktur übergeben hat. (Siehe FSINFO auf Seite 86, das die Frage der Zeitgranularität behandelt).
diropargs3
struct diropargs3 {
nfs_fh3 dir;
filename3 name;
};
Die diropargs3-Struktur wird in Verzeichnisoperationen verwendet. Das Datei-Handle, dir, identifiziert das Verzeichnis, in dem die Datei, name, manipuliert oder auf sie zugegriffen werden soll. Siehe zusätzliche Kommentare in Dateinamenkomponentenbehandlung auf Seite 101.