Zusammenfassung

  • RFC 1094 unterscheidet den Verzeichniseintrag von einer lokal gehaltenen Dateireferenz: Ein zustandsloser NFSv2-Server kann den offenen Zustand eines entfernten Prozesses nicht kennen und daher dessen Fortbestand nicht selbst garantieren.
  • Als Anpassung beschreibt das Dokument eine Umbenennung beim Löschen und die spätere Entfernung nach dem Schließen. Es legt weder ein einheitliches Namensschema noch eine Wiederherstellung nach einem Client-Ausfall fest.

Gelöscht ist keine vollständige Lebenszyklusbeschreibung

Ein Nutzer entfernt eine Datei. Kurz darauf liest ein Prozess weiter, der sie schon geöffnet hatte. Was wie ein Widerspruch aussieht, sind zwei verschiedene Tatsachen: Der Name gehört zum Verzeichnis; die offene Referenz gehört zum lokalen Betriebssystemprozess. Manche lokalen Systeme halten die zweite Beziehung aufrecht, obwohl die erste verschwindet.

Über NFS liegen diese Beobachtungen auf verschiedenen Rechnern. Der Client kennt den Prozess und dessen Öffnung. Der Server sieht einzelne Protokollaufrufe und verwaltet das exportierte Verzeichnis. Sobald er einen Löschaufruf ausführt, bekommt er nicht automatisch die Information, dass ein Prozess auf einem anderen Rechner die Datei noch braucht.

Die im März 1989 veröffentlichte RFC 1094 zur zweiten NFS-Version benennt diesen Unterschied ausdrücklich: Ein zustandsloser Server kann die Semantik, eine geöffnete Datei nach dem Entfernen ihres Namens weiter zu verwenden, nicht selbst bereitstellen. Der Client könnte den Eintrag zunächst umbenennen und erst nach dem lokalen Schließen endgültig entfernen.

Die Aussage ist enger als eine allgemeine Kritik an NFS. Die RFC verspricht nicht, jede lokale Dateisystemkonvention über das Netz zu übertragen. Sie markiert, welche Information dem Server fehlt, und skizziert eine Anpassung dort, wo diese Information vorhanden ist.

Das Protokoll überträgt Operationen, keine offene Sitzung

NFSv2 definiert unter anderem LOOKUP, READ, WRITE, CREATE, REMOVE und RENAME. REMOVE bezeichnet ein Verzeichnis und einen Namen. Eine entfernte OPEN-Operation, die dem Server den Beginn einer lokalen Dateinutzung meldet, und ein passendes CLOSE für die letzte Referenz gehören nicht zu dieser Schnittstelle.

Bei Dateioperationen verwendet der Client ein vom Server ausgegebenes Filehandle. Es verweist auf ein Objekt, zählt jedoch nicht die Prozesse, die es lokal geöffnet haben. Der lokale Kernel kann einen open()-Aufruf bedienen, ohne dafür einen gleichartigen NFSv2-Aufruf an den Server zu senden. Später erreicht den Server REMOVE, obwohl die lokale Anwendung noch nicht geschlossen hat.

Damit erklärt sich, warum ein Filehandle keine Open-Sitzung ersetzt. Der Server erhält einen Verweis für Operationen, aber keine vollständige Meldung über die Prozessbeziehung. RFC 1094 verbietet dem Client nicht, diese Lücke zu überbrücken. Sie sagt, dass der Server ohne diese Zusatzinformation nicht allein für die lokale Semantik sorgen kann.

Die Umbenennung verschiebt den Eingriff am Verzeichnis

Beim vorgeschlagenen Ablauf entfernt der Client den ursprünglichen Namen nicht sofort, sondern benennt ihn um. Für den Nutzer ist der alte Name verschwunden. Im Verzeichnis des Servers bleibt ein anderer Eintrag, bis der Client vom Ende der lokalen Öffnung weiß und ihn entfernen kann.

So werden Namenssichtbarkeit und Speicherfreigabe zu unterschiedlichen Zeitpunkten beobachtbar. Eine einzelne Benutzeraktion verteilt sich über Client und Server: Der Client verbirgt den Namen; der Server entfernt den verbleibenden Eintrag später. Diese Verteilung macht die Clientseite zum Träger einer zusätzlichen Verwaltungsaufgabe.

Die RFC legt weder den Namen des Zwischeneintrags noch Kollisionsverhalten oder die Behandlung eines Client-Neustarts vor dem Schließen fest. Auch beschreibt sie nicht, was andere Clients währenddessen sehen. Aus dem Vorschlag eine vollständige verteilte Transaktion oder die Eigenschaft eines konkreten Produkts abzuleiten, ginge über die Quelle hinaus.

Eine verzögerte Bereinigung kann ausfallen oder länger dauern; das lässt sich aus dem Ablauf als Möglichkeit ableiten. Die RFC misst jedoch keine Häufigkeit und berichtet keinen konkreten Betriebsfall. Dafür wären Implementierungsquellen, Produktunterlagen oder Tests erforderlich.

Zustandslosigkeit galt für die Protokollbeziehung

Das Ziel war, den Zustand zu begrenzen, den ein Server für einzelne Clients im Protokoll halten musste. Nach einer Unterbrechung sollte der Client Aufrufe wiederholen können, ohne mit dem Server eine Sitzung aller offenen Dateien neu aufzubauen. Dateien, Attribute, Verzeichniseinträge und gespeicherte Daten verschwanden dadurch nicht; sie blieben Zustand des Dateisystems.

Eine offene Referenz entsteht zunächst im lokalen Betriebssystem. Aus der Liste der NFSv2-Aufrufe lässt sich ihre Lebensdauer nicht ablesen. Dateisperren und Sperren für Datensätze behandelte die RFC als getrennte Dienste. Der Protokollumfang war also eine Entscheidung darüber, welche Beziehungen über die Leitung koordiniert wurden.

NFSv3 behielt eine Prozedurschnittstelle ohne entfernte OPEN- und CLOSE-Aufrufe. RFC 7530 für NFSv4 führt solche Operationen und stateid-Werte dagegen ausdrücklich auf. Das belegt weder eine flächendeckende Migration noch identisches Verhalten aller Kombinationen. Es zeigt eine spätere Entscheidung, Öffnungszustand in die Koordination des Protokolls aufzunehmen.

Die fehlende Information bestimmt die Zuständigkeit

Der Server verwaltet das exportierte Verzeichnis und führt REMOVE aus. Der Client weiß, welche lokalen Prozesse die Datei noch verwenden. Solange diese Information nicht übertragen wird, kann der Server den sicheren Zeitpunkt der endgültigen Entfernung nicht allein bestimmen. Die Umbenennung verbindet beide Sichtweisen, indem der Client die Entscheidung bis zum Ende der Öffnung aufschiebt.

Das verlangt vom Client Buchführung und eine Bereinigung, deren Verhalten bei Neustart geklärt sein muss. Der Anwendungsverantwortliche sollte wissen, ob die konkrete Kombination aus Client und Server die benötigte Semantik abdeckt. Der Serverbetrieb muss erklären können, warum nach dem Verschwinden des sichtbaren Namens noch ein Eintrag besteht. RFC 1094 verteilt diese Aufgaben nicht in Form einer vollständigen Betriebsrichtlinie.

Es gibt drei mögliche Wege: eine verifizierte Clientanpassung verwenden, die Anwendung vor dem Entfernen schließen lassen oder eine spätere Protokoll- und Implementierungskombination für genau diesen Ablauf prüfen. Jeder Weg verschiebt Aufwand in eine andere Schicht. Ein erfolgreicher Mount beweist nicht, dass alle lokalen Dateisystemversprechen erhalten bleiben.

Als Folge können Verzeichnisansicht und belegter Speicher auseinanderlaufen. Backup-, Quota- und Aufbewahrungsberichte könnten unterschiedliche Schichten messen. Das irreversible Risiko ist eine zu frühe Entfernung von Daten, die ein offener Prozess noch benötigt; das Gegenrisiko ist ein verwaister Zwischeneintrag, der Speicher bindet. Das Dokument zeigt die Grenze, nicht die Wiederherstellungs- oder Aufbewahrungsrichtlinie des späteren Betriebs.

Quellen und Reichweite der Aussagen

Die Quellen belegen Spezifikationen und Designüberlegungen. Sie zeigen nicht, wie verbreitet das Umbenennungsverfahren war, wie ein bestimmter Client nach einem Ausfall aufräumte oder wie oft dieser Fall im Betrieb auftrat.