Zusammenfassung

  • Pfadnamen dienen NFS zur Suche; spätere Operationen verwenden einen undurchsichtigen Filehandle des Servers. Der Client darf dessen Bytes weder als Inode noch als Speicheradresse oder serverübergreifende Identität auslegen.
  • NFSv4 unterschied persistente von flüchtigen Handles. Persistente Werte bleiben während der Objektlebensdauer über Neustart und Migration stabil; flüchtige dürfen unter offengelegten Bedingungen verfallen.
  • NFS4ERR_STALE meldet ein entferntes oder nicht verfügbares Bezugsobjekt. NFS4ERR_FHEXPIRED kann bedeuten, dass nur eine temporäre Referenz ihre Kontinuität verlor. Eine Wiederherstellung löst Namen neu auf und prüft das Ergebnis, statt alte Bytes umzudeuten.

Ein laufender Auftrag nach der Umbenennung

Ein Rechenauftrag hat /daten/entwurf geöffnet. Während er arbeitet, wird die Datei nach /daten/archiv umbenannt. Der Pfad hat sich geändert; daraus folgt nicht, dass das zuvor gefundene Objekt ein anderes wurde. Bei Hardlinks führen sogar zwei Namen gleichzeitig zur selben Datei.

Schon NFSv2 trennte den Weg vom Bezug. RFC 1094 beschrieb 1989 die Auflösung Komponente für Komponente. Ein separates Mount-Protokoll lieferte einen ersten Handle. LOOKUP erhielt den Handle eines Verzeichnisses plus einen Namen und gab den nächsten Handle zurück. GETATTR, READ oder WRITE arbeiteten danach mit diesem Wert.

Der Handle war 32 Byte lang und ausdrücklich undurchsichtig. Das versprach weder Verschlüsselung noch Geheimhaltung. Es bedeutete, dass der Client keine vertragliche Struktur erkennen durfte. Selbst wenn ein Server Gerätenummern, Inodes oder Tabelleneinträge verwendete, waren diese Details kein NFS-Format für Clients.

RFC 1813 machte nfs_fh3 in NFSv3 variabel lang. Der Server konnte jene Informationen unterbringen, die er zur Unterscheidung einer Datei brauchte. LOOKUP, CREATE, LINK und READDIRPLUS konnten den Wert liefern. Damit ließ sich die interne Ablage ändern, ohne jeden Client an ihre Darstellung zu binden.

Gleichheit ist stark, Ungleichheit schwach

Bei zwei Handles desselben Servers gilt: Gleiche Bytes bezeichnen dieselbe Datei. Verschiedene Bytes beweisen jedoch nicht, dass es verschiedene Dateien sind. Eine eineindeutige Abbildung zwischen Objekt und Handle ist nicht vorgeschrieben.

RFC 1813 nennt den Vergleich deshalb eine Leistungsoptimierung und keine Grundlage korrekter Entscheidungen. NFSv4 behielt diese Regel. Zwei Hardlink-Namen sollten denselben Handle ergeben. Aus jedem abweichenden Wert darf ein Client dennoch keine eigene, verbindliche Objektgrenze ableiten. Auch zwischen beliebigen Servern entsteht durch Bytevergleich keine globale Identität.

Ein Cache darf erkannte Gleichheit nutzen, um Arbeit zu sparen. Er darf nicht aus Ungleichheit schließen, dass zwei Operationen nie dasselbe Objekt erreichen. Der Server bleibt die Instanz, die seine Referenzen auf Dateien abbildet.

Aus Haltbarkeit wurde eine benannte Eigenschaft

Mit RFC 3010 führte NFSv4 persistente und flüchtige Filehandles ein. RFC 7530 und RFC 8881 führen das Modell fort.

Ein persistenter Handle bleibt während der Lebensdauer eines Objekts fest. Ein Serverneustart macht ihn nicht ungültig. Auch bei einer Migration soll der Bezug erhalten bleiben. Der Speicherort darf wechseln, ohne dass Clients die innere Verlagerung verstehen müssen.

Persistenz bedeutet nicht Unsterblichkeit. Wird das Objekt gelöscht oder sein Dateisystem nicht mehr verfügbar, folgt NFS4ERR_STALE. Der alte Handle darf nicht unbemerkt auf ein neues Objekt zeigen, nur weil dieses eine wiederverwendete interne Position belegt.

Manche Umgebungen können dieses Versprechen nicht durchgehend halten. Hierarchischer Speicher, Betriebssystemgrenzen, Migration oder beim Start neu aufgebaute Tabellen können die Zuordnung verlieren. NFSv4 erlaubt dafür flüchtige Handles und lässt den Server über fh_expire_type die möglichen Verfallsbedingungen angeben.

Die Spezifikationen zeigen beispielhaft eine Kodierung aus Startzeit, Tabellenplatz und Generation. Nach Wiederverwendung eines Platzes passt die alte Generation nicht mehr. Das ist kein vorgeschriebenes Format. Standardisiert wird die von außen erkennbare Semantik, nicht die interne Datenstruktur.

Stale und expired beantworten verschiedene Fragen

NFS4ERR_STALE besagt, dass der erwartete Bezug nicht mehr erreichbar ist. Das Objekt wurde entfernt oder das Dateisystem eines persistenten Bezugs ist nicht verfügbar.

NFS4ERR_FHEXPIRED sagt etwas über einen flüchtigen Handle. Eine Zuordnungstabelle kann beim Neustart verschwunden, eine Generation gewechselt oder eine Migration über die zugesicherte Grenze hinausgegangen sein. Das Objekt kann trotzdem noch existieren. Nur die alten Bytes gelten nicht mehr als fortlaufende Referenz.

Wer beide Ergebnisse als „Datei fehlt“ darstellt, meldet bei bloßem Referenzverlust fälschlich Datenverlust. Wer beide als vorübergehend behandelt, versucht ein gelöschtes Objekt endlos erneut. Die Fehlercodes beseitigen Unsicherheit nicht. Sie verhindern, dass die untere Schicht mehr Gewissheit behauptet, als sie besitzt.

Neu auflösen heißt neu beobachten

NFSv4 stellt besondere Root-Handles und Namensraumoperationen bereit. PUTROOTFH setzt den Ausgangspunkt, LOOKUP geht die Komponenten entlang. Hat der Client die Namen behalten, kann er nach einem abgelaufenen Handle einen neuen Bezug ermitteln.

Inzwischen kann jedoch jemand die Datei umbenannt, gelöscht oder unter dem alten Namen ersetzt haben. Der erneute Pfad führt möglicherweise zum ursprünglichen Objekt, zu einem Ersatz oder ins Leere. Attribute, Sperren, Cachezustand und ausstehende Operationen müssen deshalb neu geprüft werden.

Auch Berechtigung ist eine getrennte Beziehung. Ein gültiger Handle ist keine Lese- oder Schreibvollmacht. Der Server prüft Zugriffe pro Operation. Eine erfolgreiche Neuauflösung erneuert weder eine alte Sperre noch beweist sie, dass eine unterbrochene Änderung gefahrlos wiederholt werden kann.

Die historische Leistung des NFS-Handles liegt in seiner begrenzten Aussage. Der Server bestimmt die interne Abbildung und meldet deren Kontinuität. Der Standard setzt wenige gemeinsame Regeln: Undurchsichtigkeit, begrenzte Gleichheit, Lebensdauerklassen und ehrliches Scheitern. Der Client bewahrt den Namenskontext und akzeptiert, dass eine verlorene Identität neu belegt werden muss.

Ein Pfad kann wechseln, ohne dass das Objekt wechselt. Ein Objekt kann bestehen, obwohl sein Handle verfällt. Ein Handle kann gültig sein, obwohl die Operation verboten bleibt. Erst die Trennung macht das System beherrschbar.

Quellen