Zusammenfassung

  • NFSv2 ließ verändernde Operationen erst nach stabiler Speicherung zurückkehren. Das vereinfachte die Erholung eines zustandslosen Servers, band aber jeden Schreibaufruf an die Persistenzlatenz.
  • NFSv3 führte UNSTABLE, DATA_SYNC und FILE_SYNC ein. Die Antwort nannte die tatsächlich geschriebene Länge, den erreichten Grad und einen undurchsichtigen Write Verifier.
  • Bis COMMIT oder ein stärkeres Ergebnis vorlag, bewahrte der Client die Daten auf. Ein geänderter Verifier machte alte instabile Bereiche zu Wiederholungskandidaten.

Ein Erfolg, der Speicher beim Client belegte

Auf ein entferntes WRITE folgt NFS3_OK. Trotzdem kann committed den Wert UNSTABLE tragen. Der Aufruf war erfolgreich, doch die Bytes sind womöglich nur im RAM des Servers angekommen. Protokollabschluss und Überleben eines Neustarts sind verschiedene Aussagen.

RFC 1094 beschrieb NFSv2 mit synchronen Änderungen. Nach der Antwort durfte der Client stabile Speicherung annehmen und seine Kopie verwerfen. Das passte zum stateless server: Nach einem Ausfall wiederholte der Client Operationen, statt Sitzungszustand wiederherzustellen. Der Preis war Wartezeit auf dem dauerhaften Pfad.

RFC 1813 bezeichnete genau dies als Durchsatzengpass. Die „sicheren asynchronen Schreibvorgänge“ von NFSv3 waren nicht schon bei der frühen Antwort sicher. Sicher war die vollständige Kette, weil Daten, Status und Erholungsregel erhalten blieben.

Drei Stufen statt eines überladenen OK

Der Request wählt UNSTABLE, DATA_SYNC oder FILE_SYNC. Bei FILE_SYNC müssen Daten und sämtliche Dateisystemmetadaten vor der Antwort stabil sein. DATA_SYNC verlangt Daten und genug Metadaten, um sie wiederzufinden. UNSTABLE erlaubt dem Server, alles, einen Teil oder nichts vorher zu persistieren.

Das Antwortfeld committed berichtet die tatsächlich erreichte Stufe. Ein Server darf stärker liefern als verlangt. count nennt zusätzlich die wirkliche Länge, denn ein Short Write kann erfolgreich sein und dennoch einen Rest übriglassen. Damit sind Anfrageumfang, angenommener Bereich und Dauerhaftigkeit getrennt.

Der verf genannte Cookie bleibt innerhalb einer relevanten Serverinstanz konstant und muss sich ändern, wenn eine neue Instanz uncommitted Daten verloren haben kann. Ein Reboot ist der Normalfall. Entscheidend ist aber der Bruch der flüchtigen Verwahrung.

Der Verifier ist kein Inhalts-Hash. Gleiche Werte beweisen weder eine unveränderte Datei noch vollständige Länge oder fehlende Konkurrenz. Unterschiedliche Werte beweisen nicht den Verlust jedes Bytes. Sie entziehen lediglich der Annahme die Grundlage, dass die alte volatile Kopie noch existiert.

COMMIT verband zwei Zeitpunkte

Nach einem instabilen Ergebnis hält der Client seinen Buffer. RFC 1813 beschreibt drei Zustände: dirty, done but needs to be committed und done. Die mittlere Stufe ist der Preis der frühen Antwort. Netzwerkübertragung und Verwahrung sind beendet, die Persistenzpflicht bleibt offen.

COMMIT zwingt zuvor instabile Änderungen in stabilen Speicher. Es kann einen Bereich bezeichnen; Offset null und Count null reichen vom Dateianfang bis zum Ende. Ein erfolgreicher COMMIT liefert wiederum einen Verifier.

Stimmt er mit den WRITE-Antworten überein, können Annahme und Persistenz derselben Serverinstanz zugeordnet werden. Hat er gewechselt, muss der Client die alten UNSTABLE-Bereiche als möglicherweise verloren behandeln und an ihren bekannten Offsets erneut schreiben.

Diese Regel behauptet nicht, dass tatsächlich alles verschwunden sei. Ein Teil kann vor dem Ausfall auf dem Medium gelandet sein. Ohne feinere Evidenz ist Wiederholung jedoch die sichere Handlung. Umgekehrt ist ein gleicher Cookie noch kein Beweis für richtigen Inhalt; Status, Count, Range und Koordination mit anderen Schreibern bleiben nötig.

Stabil war keine absolute Eigenschaft

RFC 1813 beschreibt stable storage als widerstandsfähig gegen wiederholte Stromausfälle, bestimmte Hardwarefehler sowie Softwareabstürze und Reboots. Der Ausfall des stabilen Speichermoduls selbst liegt ausdrücklich außerhalb der Definition. Backup, Replikation und logische Korrektheit folgen daraus nicht.

Auch strikte Cache-Konsistenz zwischen Clients wird nicht versprochen. Dauerhaftigkeit beantwortet, ob Bytes eine Fehlerklasse überleben; Konsistenz beantwortet, welche Fassung gelten soll. Ein COMMIT kann das erste leisten, ohne das zweite zu entscheiden.

RFC 3530 und RFC 7530 führten das Prinzip in NFSv4 fort. RFC 8881 schreibt ausdrücklich vor, bei geändertem Write Verifier alte als UNSTABLE4 beantwortete Daten als verloren anzunehmen und wiederherzustellen.

Durchsatz war verteilte Arbeit

Der Server konnte Flushes bündeln und schneller antworten. Dafür trug der Client Speicher, Bereichsbuchhaltung und Replay-Kapazität. Bei einem Instanzwechsel konnte eine lange Warteschlange instabiler Daten gleichzeitig als Wiederherstellungsverkehr erscheinen. Asynchronität beseitigte Arbeit nicht; sie verschob Zeitpunkt und Eigentümer.

Auch der Client konnte vor dem späteren COMMIT ausfallen. RFC 1813 erwähnt ausdrücklich, dass der Folgeaufruf wegen eines Clientfehlers ausbleiben kann. Ein korrekt angebotener Erholungspfad garantiert also nicht, dass jede Anwendung ihn abschließt. Wer einen instabilen WRITE-Erfolg als Abschluss eines Geschäftsvorgangs ausgibt, erweitert die Aussage über ihre Protokollgrenze hinaus.

Die Möglichkeit, stärker als verlangt zu antworten, war dabei mehr als eine Optimierung. Sie erlaubte einer Implementierung mit schneller nichtflüchtiger Technik, ihren Vorteil ohne neues Clientwissen weiterzugeben. Der Client musste keine Hardware erraten; er durfte allein das gelieferte committed auswerten. Schwächere Implementierungen konnten die offene Pflicht ehrlich anzeigen, stärkere sie früher schließen.

Bereichsbezogenes COMMIT erzeugte eine weitere Entscheidung. Kleine Bereiche können Client-Puffer schneller freigeben, verursachen aber mehr Aufrufe. Große Bereiche bündeln Arbeit, halten jedoch mehr Wiederherstellungsdaten länger fest. Diese Wahl betrifft nicht nur Durchsatz, sondern auch die maximale Menge, die nach einem Verifier-Wechsel erneut über Netz und Speicher laufen muss.